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-user
mailing list