Looking for new leader for mRemoteNG

[rmcardle]

[dmsparer]

I am willing to take some sort of role in keeping the project going. Most of my experience is in Ops/ITSM, but I am also a reasonably competent programmer (C#/.Net). I can do a video call sometime to meet, discuss my credentials, etc.

[dennis-360ict]

Hi, if you could create revenue out of mRemoteNG, how much would you need? We're spending ~600eu a year for ASG Remote and mainly for the functionality to share credentials within our group. How much would you need to give the project another chance? We could do a kind of crowdfunding to get the product supported for X months or something? I'm even willing to pay for you to code some kind of advertising in the product if the upside is you won't abandon the project.

Could it be an idea to get funded for bugfixes/functionality? I would pay to get the SQL DB support out of experiemental or to fix cerntain bugs or get new OS support, or for a guaranteed period of you not leaving (which doesn't mean you actualy have to bugfix/features, just not leaving).

[kturgeon]

So been trying to determine what project I am going to follow now, and here are the two forks that seem to be going on:

https://github.com/bkbartk/dRemote
https://github.com/kmscode/mRemote3G

Both look like they are being actively worked on, so at this point I am not sure which one I should use.

Anyone have any thoughts on these two projects (or if there is another fork that I didn't see)?

-K

[dmsparer]

I still believe the best solution is to remerge downstream projects back into mRemoteNG and have those project managers take over. However, based on the type of posts on this thread so far, I'm not sure there is enough support to continue development of this project. I'd still like to see this project survive, but more folks will need to step up to actually perform the work.

If mRemoteNG is discontinued, the next best thing we can do is try to merge downstream projects into 1 successor in order to prevent diluting resources.

[rmcardle]

[devonn]

For what it is worth I am throwing my hat in with dmsparer and his suggestion that it be left as mRemoteNG with a properly managed community. Even though I just joined the forum I've been using mRemoteNG since it started and mRemote before that throughout my career as a developer, DevOps and now as a manager. I would also suggest that as part of the transititon the site be moved to github and githubs bug feature be turned on for the project so that they can be tracked through their and pull requests can reference bugs etc.

I use mRemoteNG enough that I'd be willing to contribute where I can.

[aixtools]

The other thing to look at is getting permission to change the license.

I would assume the current license is from mRemote.

If the "owner" of that would declare it public domain, no reservations, then I would suspect that a deriative (whether dRemote or mRemoteNexGen) would be able to make changes to the license they use/maintain.

A reason for not doing that (by the original owner) is because they see it as a source of income, etc.. But licenses are not set in stone. An owner can change licenses - I have seen projects change licenses before (e.g., look at python, still opensource).

The point about opensource should never be that you cannot charge for what you do, usually it is just that you cannot charge a license fee.

So, e.g., you have a low-support version for "anyone", but for quick support, email support, etc, you request/receive a support fee.

Way back when, the principle of OSF was not that software is free, but access to the source should be free aka open so that should support for an application stop a person or business could at least consider continuing "self-support" rather than be stuck in a dead-end.

So, just remember OSF does not mean free == no charge, but free == open, easy access to source

And, although I am only a user as of today - this is something I have seen in many places - and it clearly fills a need.

And with all the changes in OpenSSL requirements on clients, something is probably needed real soon, or mRemoteNG will also go the way of my current ssh (with multi-window support) client ( sadly, no TLS1.2 support).

Please accept this virtual "soda", or if you prefer - this virtual "beer".

Michael

[dmsparer]

As an impromptu announcement, I've decided to take over the project. I am currently working with rmcardle to get accounts transitioned and I am studying the codebase to get up to speed. This will be a process and not likely a speedy one. However, part of this time will be spent planning the long term requirements of the project such as:
- large-scale rewriting of the codebase required for some bug fixes and feature requests
- making the project easier for newcomers to contribute (mainly through documentation)
- triaging the significant backlog currently in Jira

[kcmjr]

I just saw the goings on in the forum and wanted to add my 2 cents worth. I love this tool, and have used it diligently since first discovering it many years ago. I've also used ASG Remote and while I like aspects of where it has gone, I still prefer good ol' mRemoteNG. It's pained me to see the lack of development but I completely understand Riley's issues and point of view having run free public access BBS systems back in the 90's and never seeing a penny from it. I'm not a programmer, mainly a high level scripted, but I believe in the tool enough to want to help out where I can. Since I'm here after the point where someone has already taken over the reigns I will simply throw my hand up, say I'm here, and wait to see what boils to the surface.

I also agree that the project should stay free and open. Please do make sure that some vetting process is used to make sure people on the project team are appropriate for the task.

Ken M.