Gnucash: A plea for help

[iphitus]

This was forwarded on to my Lug mailing list:

 

-------- Original Message --------

Subject: State of the GnuCash project: A call for help

Date: Sun, 10 Aug 2003 23:29:12 -0400

From: Benoit Grégoire <bock@step.polymtl.ca>

To: gnucash-devel@gnucash.org, gnucash-user@gnucash.org

 

 

 

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/

 

_______________________________________________

gnucash-user mailing list

gnucash-user@lists.gnucash.org

http://www.gnucash.org/cgi-bin/mailman/lis...fo/gnucash-user