Hi, On Thursday 20 October 2016 00:31:29 Lincoln A Baxter wrote:
> 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? I can certainly answer that: No it is not a fork, even though some concepts are similar/inspired by GnuCash and it uses the same backends like AqBanking and libOFX provided as separate libraries. Regards Thomas > 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 -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA ------------------------------------------------------------- Any sufficiently advanced bug is indistinguishable from a feature. (Rich Kulawiec) -------------------------------------------------------------
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel