State of the GnuCash project: A call for help

BenoitGrégoire bock at step.polymtl.ca
Mon Aug 11 00:29:12 CDT 2003


This is an article I wrote after several discussions about GnuCash's future 
over the last few weeks.  I believe that it is important for everyone to take 
the time to read it completely.  

-----------------------------------------------------------------------------------------------------
STATE OF THE GNUCASH PROJECT, A CALL FOR HELP

The GnuCash project is having a hard time.  I think most everyone agrees that 
GnuCash is a critical piece of software for the Linux desktop.  It's also one 
the largest free software projects.  How big is it?  GnuCash currently has 
287,853 physical source lines of code (SLOC).  For example, had the current 
GnuCash CVS been included in RedHat 7.1, it would come in 21st position in 
code size (see http://www.dwheeler.com/sloc/).  At that time,  the current 
GnuCash CVS source would have been pretty similar in size to qt, postgresql 
or perl, about 60% of Gimp and between 12% and 16% of Xfree, Mozilla or the 
Linux kernel.  Although GnuCash comes up in every discussion of needed 
software to get Linux on the desktop, the GnuCash project currently has only 
about seven active developers (active being used very loosely here, 
considering I included myself) and enjoys far less exposure than many 
projects of a similar size.

We may be headed for a dead end if we don't reorganize and refocus our 
efforts.  GnuCash badly needs more manpower (not just developers), and needs 
to get it quickly.  


* How did we get here

Of course, every project could always use more developers, but the consecutive 
demise of both Gnumatic and Linux Developers Group caused the loss of most of 
GnuCash's core developers two years ago.  The few volunteers that were left 
focused on new features, in the hopes of attracting users and hopefully also 
developers.  We've managed to take it to 1.8.5 (to be released in a few 
days), and in the process GnuCash gained Small Business features, Scheduled 
Transactions, a completely new import UI with Bayesian filtering, OFX and 
HBCI support, Mortage and Loan Repayment druid, and many, many others.  We 
are very proud of it and we clearly have more users judging from traffic on 
gnucash-users, and all should now be well in GnuCash-land.

Not quite.  We didn't attract many new developers and all those new features 
have to be maintained and debugged.  They also represent a huge tech support 
burden, since most of  the features were not documented properly due to time 
constraints.  GnuCash has grown too large for the current developers to 
properly debug and maintain the current code base, add new features and write 
documentation, all at the same time.

I hate to admit it, but in our quest for new features,  choices had to be made 
and a lot of important things are currently being neglected.  If the GnuCash 
project can't manage to attract more contributors and refocus the efforts of 
those it already has, it's going to become unmanageable.  We often say that 
Linux would survive even if Linus got hit by a bus.  Well, right now I am not 
too certain that GnuCash would currently survive if Derek Atkins got hit by a 
bus.

So now I'll try to suggest some solutions.


* 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.  "Casual" hacking on GnuCash to scratch an 
itch is much to hard, even for an experienced developer.

-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.
We must also write a report writing Howto:  We already have some very powerful 
reports, but this is the single most common offer for help we receive "Hi, 
I'd like to write "foo" report for GnuCash, can someone help me or point me 
to documentation on that subject".  Sometimes I wonder if anyone knows 
anymore...  So the answer is always the same:  'there isn't any; use the 
source Luke'.  We are wasting the chance to hook countless new developers.

-Fix core capabilities in the engine:
Existing developers should focus on architecture issues and completing 
existing core features that only they can realistically tackle, such as Lots 
(which are needed to support accounting periods) or fixing the problems in 
the scheduled transactions, so that new developers can build on that 
functionality.

-Improve interoperability with other software or new modules:
GnuCash has a great, powerful multi-user financial engine that many people ask 
to plug into.  Unfortunately much of this power is locked away.  There is no 
way to interface with a running GnuCash (the RPC backend and perl bindings 
have bitrotted), there is no way to start a new instance  while passing 
parameters like "import this file".  We need a wrapper that will start 
GnuCash if it isn't already started and pass API requests to it, with or 
without GUI.  The current module system needs to be completed or replaced.  
It's hard for new developers to integrate new modules in the build and menu 
system (we need a howto on that too...).  Also, data import isn't enough, we 
must also support export to inter-operate with other software.  (LibOfx 
http://libofx.sf.net should get us there if I can just find time to work on 
it).

I think fixing/developing external interfaces and writing additional import 
and export support should greatly help our developer crunch in the medium 
term, by consolidating part of financial software development in the free 
software ecosystem.  We have received many, many inquiries from people 
wanting to integrate gnucash with (name of web system, database, payroll, kde 
front end or whatever).  We can't afford to loose these people, whether or 
not the core developers like their pet project.  We must use the gnome 2 port 
as an opportunity to finish/cleanup/document our interfaces and from then on 
answer "I don't know if your idea will work, but you're welcome to try; 
here's the relevant documents to get you started."


* 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).

-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.

-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.

-Spend less time answering some types of questions:
Considering the current developer crunch, core developers should plan to at 
least halve their time spent justifying the absence or incompleteness of 
feature X, or answering basic user questions directly on mailing lists and 
IRC.  Yes, it will decrease the level of service to our users, but diverting 
so much time for the few core developers is doing them a long term 
disservice.  And if the website is kept up to date, the Wiki is implemented 
and fed by developers every time an interesting question comes up, and the 
mailing list can be searched easily, it's should be easy for other users to 
fill in.


* What users should do

You can help developers a great deal by helping each other!  Hang on #gnucash 
on irg.gnome.org, subscribe to gnucash-users (and gnucash-devel if you like 
to follow development) at http://www.gnucash.org/en/lists.phtml.  Try to 
answer questions there.  Developers do not have time to answer every single 
question and many are left unanswered.  Don't be afraid to look stupid, if 
your are not sure start with "I think" and if your answer is incorrect, don't 
worry, the developers do monitor those channels and will correct you.


* Conclusion

I am optimistic that everything will work out.  Not everything is dim, much of 
what I mentioned is beginning to be worked on, and new contributors have 
recently started to work on various parts of the GnuCash project.  My goal by 
writing this piece is to convince current developers that after 1.8.5 we must 
pause to do some much needed project management, and to inform our users and 
potential developers that we badly need their help.

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...
----------------------------------------------------------------------------------------------------------

Good night,
-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/



More information about the gnucash-devel mailing list