Our packaged version had over 100,000 users (possibly more than the zipped version at the time IIRC) and we didn't want to strand them and his version didn't have an updater that worked for portable users because it required admin rights. This was due to a bug that had already been corrected and his worries of ongoing support of our users. We ran into a situation where the dev that originally approached us asking us to package his open source app for use by our users decided he didn't want us packaging it anymore after it had been available for over 3 years. We'd prefer to never do a fork and have submitted changes upstream where we can.

Furthermore, every Github page has a 'fork' button at the top of the screen so I'm mystified when someone panics on this topic. Still, there's a big bone in my body that feels forking is very defensible, especially after the clear success of LibreOffice over OpenOffice. Additionally, open code is supposed to be about community so you can't just set aside the developer's feelings. forks tend to be accompanied by a great deal of strife and acrimony between the successor groups' ). Webfork wrote:From what I understand, forking is a dramatic step that should generally be considered a last resort ('.

That said, I wasn't there and I don't know what you were dealing with.

Unfortunately, we had exceedingly bad luck with the last project we forked to ensure our users could continue using it easily when the developer went a bit crazy on us.įrom what I understand, forking is a dramatic step that should generally be considered a last resort ('. JohnTHaller wrote:I'd love to have a working FreeFileSync that is both (1) launchable from other processes like our platform and (2) properly portable so all our cloud users can use it.

Freefilesync github