State of the GnuCash project: A call for help

Christian Stimming stimming at tuhh.de
Mon Aug 11 13:01:04 CDT 2003


Benoit: Thanks for writing this up. I totally agree with the overall 
state of the project. I also agree with your conclusions about what to 
do. We might consider posting this article and/or a link to this to 
gnomedesktop.org, and maybe even to /. ?

I just got a couple of comments to some points. (If this article were in 
a wiki, I'd add them directly in the text.)

Benoit Grégoire schrieb:
> * What core developers should do to help future developers
> 
> There are many reasons for our difficulties to attract developers and other 
> contributors, but it all comes back to the same problem:  real or perceived, 
> the barrier to entry is too high.  To get more developers, we must make it 
> easier to contribute to GnuCash.  

Absolutely.

> -Work on the developer documentation problem:
> There is no complete and current architecture and API reference.  Now that 
> we've put the doxygen plumbing in place, we must make sure that ALL functions 
> that are in public headers ARE documented, even if only by saying "Document 
> me!", so the doxygen docs become truly authoritative.  Then put the docs on 
> the web site.

Totally agreed. Actually I (and you, too) spent quite a few months ago 
to doxygen-ify the most important header files. Nevertheless there is 
still a lot of documentation to be done. Especially some short writeups 
about "how the pieces stick together" i.e. one level above single 
function calls would be necessary.

> -Improve interoperability with other software or new modules:
> Also, data import isn't enough, we 
> must also support export to inter-operate with other software.  

Absolutely. It's kind of unfair to entice people into using gnucash but 
locking them in because there is no QIF or OFX export. However,  the 
core developers by definition don't see the missing export facilities as 
personal itch, and thus they don't get written... :-)

> * What developers should do to help users and decrease developer load
> 
> -Make sure the mailing lists are easily searchable:
> And/or document how to properly search them (Google isn't cutting it).

Mailing list archive with nice search functions is available at GMane, 
http://news.gmane.org/?match=gnucash TODO: Include link on website.

> -Get more people write access to the website:
> We have received many offers to help, but turned most of them down for no good 
> reason.  The website is nice, but it isn't up to date, it's a source of 
> frustration, misleading to users and future developers, and pointlessly 
> increases traffic on gnucash-user and the #gnucash IRC channel.

Absolutely. Jon Lapham should get write access to the website, but many 
other contibuters probably as well.

> -Quickly implement a Wiki or similar system: 
> This will allow us to have an effective place to point users on gnucash-users 
> and #gnucash instead of writing the same answers over and over again.  It 
> will also allow us to document bugs/workarounds for specific versions.

Totally agreed. For the Germany-specific features (HBCI etc) there is 
already a German wiki-page which has proven very helpful, 
http://linuxwiki.de/GnuCash TODO: Add link to gnucash website.

As for gnucash, we could consider using the wiki on gnomedesktop.org -- 
it's already up and running.

> Very soon, I will write a second article to list specific projects where you 
> can contribute.  Regardless of your skill set, there will be one for you...

Yes, sounds good.

<whining>
Just for the record: When I implemented the HBCI features, I tried to do 
this precisely "the right way" to enable other developers to extend this 
subsystem. I documented each and every header file, I added lots of 
comments everywhere inside the code, I made sure the OpenHBCI API is 
absolutely 100% documented (which it almost is). And as soon as any 
programming-capable people ask about new features on gnucash-de, I 
provided lots of descriptions and explanations on how to implement a 
particular change (about every 3-4 weeks). Outcome so far: Three or four 
questions interested people about tweaking the generic importer, one or 
two interested in changing the HBCI->Gnucash transaction import mapping, 
and maybe some of these guys actually managed to get their desired 
changes to compile. However, zero (in numbers: 0) patches have been 
provided back to the mailing list. In other words, even though I thought 
I had low expectations I'm still surprised about how much lower the 
actual participation from "the community" turned out to be.
</whining>

This might be different if we manage to get an article on /. -- but 
Linas, are the servers prepared to be slashdotted...?

Christian



More information about the gnucash-user mailing list