IMO, you are asking the right (hard) questions... I'm interested in seeing the response to the https://kmymoney.org/ question. Is this a fork, or not?
Lincoln On Tue, 2016-10-18 at 09:56 +0100, John Ralls wrote: > > On Oct 18, 2016, at 8:13 AM, Paul Phillips <p...@patchpitch.com> > wrote: > > > > Hi John, > > > > Indeed it is a shame, and I regret causing the discord and > suspicion. Please accept my apologies. > > > > Thanks for your insight and the link to the SFC. I shall get in > touch with them. > > > > The only other way of engaging with the GnuCash project without the > need of either a contract or management oversight is to create a > fork. It would therefore obviously be completely optional whether > the dev team adopted any of the changes. But if the fork development > matched the Gnucash roadmap and project guidelines, the chances of > merger would presumably increase. > > > > However the key to enabling this to succeed is the user base, and > as a fork, the user base starts from scratch. > > > > Paul, > > There are forks and then there are Github forks. The latter is one > usual way for "outside" developers and documentors to contribute, > submitting their work through a Github pull request (which is a bit > different and much easier to use than the traditional git email pull > request used by the Linux project. > > The other kind of fork is what happened with Open Office a few years > ago: Unhappy with the way Oracle was managing the product, a large > chunk of the development team took the code base and created a new > product, Libre Office. I think that's what would have to happen with > a "commercialized" GnuCash: The "commercial" team would have to > create a new product to work on to guarantee that the paid-for work > actually gets released in a product. > > I've put "commercial" in scare-quotes because the new product would > still be limited by the provisions of the GPL and the GnuCash project > would be able to merge any changes that they liked into the Free > version. Both because of that and the limitations of the GPL the > "commercial" entity would have to find some other way of monetizing > the product; that's normally done on open source projects by selling > support. IMO that's a hard nut to crack: Developers, documentors, and > managers are expensive and the "commercial" entity would need a > pretty hefty cash-flow; a reasonable-sized team might run as much as > $1M/year once overhead is included. > > Regards, > John Ralls > > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel