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-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel _______________________________________________ Linux-users mailing list [EMAIL PROTECTED] Unsubscribe/Suspend/Etc -> http://www.linux-sxs.org/mailman/listinfo/linux-users
