Donating money isn't going to get anything implemented. Not only is it really expensive to hire or contract for programmers, the GnuCash project doesn't have the necessary overhead resources to even try: There's no GnuCash corporate entity to make contracts and nobody in the core group with the time or inclination to find, recruit, hire/contract, or manage paid programmers--or even to create that corporate entity to make contracts.
At this point we don't even have enough programmers to make much progress on moving GnuCash forward on the published roadmap (https://wiki.gnucash.org/wiki/Roadmap) never mind the several hundred open enhancement requests, several hundred more open bugs, paying down GnuCash's huge burden of technical debt, and keeping up with technology changes in dependency packages. Regards, John Ralls > On Aug 17, 2023, at 02:43, Brad Morrison <bradmorri...@sonic.net> wrote: > > Hi Michael/all, > > It does not appear that Square lists a GnuCash app as an option - > https://squareup.com/us/en/app-marketplace Square also doesn't have Odoo > (https://www.odoo.com/) listed as an app option. > > I do not know what those kinds of technical integrations would involve, but I > assume that it would be a lot of work! > > My point in reminding people of the limits of GnuCash's capabilities is to > say that if we want to increase those capabilities, they need to be paid for. > It is unfair to expect people to donate as much to this or any open source > project as the core folks of such projects typically do. > > "If anyone is interested in expanding GnuCash's capabilities, feel free to > donate to the project here (https://www.gnucash.org/donate.phtml), just be > aware that for US based taxpayers, GnuCash is not a 501c3 registered > nonprofit and does not have a fiscal sponsor like some other open source > projects (https://sfconservancy.org/projects/current/ or > https://www.spi-inc.org/projects/), so those donations may not be tax > deductible if the taxpayer itemizes their deductions > (https://www.irs.gov/taxtopics/tc506)." > > I wouldn't mind donating my time to try to help GnuCash apply to SFC &/or SPI > to become a fiscally sponsored nonprofit, but I would need help and > permission. > > Thanks, > > Brad > > > On 8/12/23 06:39, Michael or Penny Novack wrote: >> On 8/12/2023 9:02 AM, Brad Morrison wrote: >>> Hi Gregory/Susan/Richard/all, >>> >>> I think that it is important to remember that GnuCash is an all volunteer >>> project and not an accounting system suitable for almost any type of >>> organization, other than a very simple one: >>> >>> https://github.com/Gnucash/gnucash/pull/1623#issuecomment-1583966278 - "But >>> GnuCash isn't suitable for large, or even small, enterprises and never will >>> be. GnuCash is for tiny and simple enterprises; we often say individuals >>> and sole proprietorships. Even having employees makes using GnuCash a >>> dubious proposition (no payroll module), as does carrying more than a very >>> few line items of inventory (no inventory module) or performing any sort of >>> manufacturing (no bill of materials or cost accounting modules). >> >> >> I disagree in the sense that in the days of pen and ink on paper all of >> those things were done before we had computers. Using gnucash you can do >> anything you could pen and ink on paper. >> >> What is being said is that gnucash is not an "integrated business system" >> with multiple components sending feeds to each other. Components like POS, >> inventory, payroll, etc. are not PART of ":general ledger" (gnucash as >> normally used). Those other components would be storing data that isn't >> financial as well as what is and is sent to by "feeds". >> >> For example, besides things like unit cost of batch an inventory system is >> dealing with things like shelving location, restock level, primary and >> secondary sources, etc. A POS system is tracking things like the ID of the >> sales person currently at the register. The payroll system things like >> emergency contact, length of service, etc. >> >> MY druthers? I am opposed to "monolithic" systems, much preferring "modular" >> systems << and remember, I used to work on/design LARGE systems >> If >> nothing else, makes changing and testing MUCH easier since well defined >> boundaries and data exchange between components. So while I do not think the >> developers of gnucash should tackle these other components PERHAPS it would >> make sense to make gnucash (the general ledger component) a module that >> could receive "feeds". Then others could decide to tackle one or more of >> these other parts of "a business system". Hopefully also keeping them >> modular (as they might be feeding each other as well as feeding general >> ledger. For example, POS would feed both "general ledger" (the money part of >> the sale) AND inventory (the physical part of the sale). >> >> Michael D Novack >> >> >> _______________________________________________ >> gnucash-user mailing list >> gnucash-user@gnucash.org >> To update your subscription preferences or to unsubscribe: >> https://lists.gnucash.org/mailman/listinfo/gnucash-user >> ----- >> Please remember to CC this list on all your replies. >> You can do this by using Reply-To-List or Reply-All. >> > _______________________________________________ > gnucash-user mailing list > gnucash-user@gnucash.org > To update your subscription preferences or to unsubscribe: > https://lists.gnucash.org/mailman/listinfo/gnucash-user > ----- > Please remember to CC this list on all your replies. > You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
