State of the GnuCash project
| From: | Benoit Grégoire<bock@step.polymtl.ca> | |
| To: | gnucash-devel@gnucash.org, gnucash-user@gnucash.org | |
| Subject: | State of the GnuCash project: A call for help | |
| Date: | Sun, 10 Aug 2003 23:29:12 -0400 |
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 gnucash-devel@lists.gnucash.org http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
Posted Aug 11, 2003 16:39 UTC (Mon)
by jre (guest, #2807)
[Link]
Posted Aug 11, 2003 16:43 UTC (Mon)
by freelsjd (guest, #250)
[Link]
Posted Aug 11, 2003 18:48 UTC (Mon)
by dwheeler (guest, #1216)
[Link] (2 responses)
This is not an indictment on the project.
Indeed, it's impressive that they've come this far, and the list of
"critical missing features" has steadily shortened.
For example, they once couldn't handle repeated transactions... and
now they can!
In fact, perhaps they can export data now... but I just checked their
website briefly and didn't see it (can anyone tell me otherwise?).
In fact, given all the the infrastructure they've put together, I think
the "critical missing features" list is getting rather short.
I think they WILL get more developers once they get those missing
features fleshed out.
I think they're right to focus on development to get more developers,
and that they're almost over the hump... just a little more to go.
Look at other successful open source projects with many developers.
In general, they only got a lot of developers once the program had
enough functions to be useful to some target audience.
For example, the Linux kernel project really grew once there were
market niches it was already well suited for (e.g., special-purpose
low-cost servers on x86 machines).
What seems to happen is a very small percentage of users become developers,
so if you want more developers in an open source project,
you want to create a very large user base.
The GnuCash folks have an ambitious project to support both home
users and small business users. Ambition is fine!
But GnuCash developers need to find some subgroup of users
and create a product that's "good enough" for the
basic needs of that group.
I suggest home users, for their needs are easier: most just need to keep
track of just a few accounts and compare them to a budget.
Some home users will be more willing to experiment
with a "new" product, too.
But I suspect few home users will be able to use GnuCash without budgeting.
And, with an export capability, they can use other projects and not
fear getting "stuck" with GnuCash (giving them the confidence needed
to try GnuCash).
A Windows port would also add a large number of potential users, eventually
resulting in more developers.
It would also make it easier for users to transition... first switch
to the open source applications (Open Office, Mozilla, GnuCash), and
once they've done that they can then switch operating systems.
So, my advice: focus on the home user. Add budgeting and QIF export,
enough for their needs. Then work to get lots of users
(maybe even with a Windows port).
Some of those users will become developers, and your life will get
easier. Well, at least, you'll have a different set of problems ;-).
Posted Aug 11, 2003 19:12 UTC (Mon)
by smoogen (subscriber, #97)
[Link]
Posted Aug 11, 2003 19:56 UTC (Mon)
by benoitg (guest, #13928)
[Link]
As for budgeting, there have been discussions about an implementation model in the past, but we never settled on an architecture, especially since we were waiting for Lots to be completed. But now that active work on Lots is in progress, people are most definitely welcome to start discussing it again.
Posted Aug 11, 2003 22:43 UTC (Mon)
by dank (guest, #1865)
[Link] (6 responses)
Posted Aug 11, 2003 23:49 UTC (Mon)
by roskegg (subscriber, #105)
[Link] (5 responses)
I am suprised they hang on irc.gnome.net instead of irc.gnu.org. That might help a bit.
Posted Aug 12, 2003 1:39 UTC (Tue)
by dank (guest, #1865)
[Link]
I wrote a little plugin once for Gimp in Scheme. It was a major pain in
Posted Aug 12, 2003 5:56 UTC (Tue)
by rganesan (guest, #1182)
[Link] (3 responses)
I like Lisp and it's variants, I've even tried my hand at some Emacs Lisp
Posted Aug 12, 2003 12:02 UTC (Tue)
by Per_Bothner (subscriber, #7375)
[Link] (2 responses)
It is also strange how Perl/Python are viewed as "mainstream" but Now there are styles of Scheme programming with heavy use
Posted Aug 13, 2003 5:29 UTC (Wed)
by rganesan (guest, #1182)
[Link] (1 responses)
I didn't say I had problems with Scheme. I had taken a Lisp > It is also strange how Perl/Python are viewed as "mainstream" but I am fairly confident that's a view shared by a large number of developers. I am a professional software developer and in the three companies that I've worked in over the last 10 years, Perl is certainly more "mainstream" than Scheme. In other words, I haven't come across any scheme programmers among my colleagues. I can't say the same for Python though. Hardly anybody seems to be aware of Python at the companies I've worked, but it definitely has more traction than scheme.
Posted Aug 26, 2003 15:46 UTC (Tue)
by Dareth (guest, #14475)
[Link]
Pascal,C,Java, hell even Perl. Lisp just doesn't fit the normal mold. Look at the basic Welcome or Hello World .scm file. I can follow what it is doing, but I wouldn't want to just make The comments are helpful.. but some heavy tutorials will be needed to get coders past the initial "WTF kind of code is this!" reaction.
Posted Aug 12, 2003 1:06 UTC (Tue)
by stevep (guest, #13939)
[Link] (6 responses)
What the GnuCash team need to do to attract developers is: 1) Identify dependencies (including min and max version numbers)
Posted Aug 12, 2003 7:20 UTC (Tue)
by ekj (guest, #1524)
[Link]
Get the newest version from CVS, and compile it. Unfortunately that is as far as I came, infact compiling it never worked. * It needed like 20 different libraries. So, in both cases, having wasted half a daz for what should be a 20 minute procedure, I just gave up. I strongly suspect there are dozens of other programmers with similar experiences.
Posted Aug 12, 2003 10:31 UTC (Tue)
by guybar (guest, #798)
[Link] (2 responses)
why not, instead: 1) create a single directory-tree including _ALL_ the libraries and tools that gnucash needs, for the current dev. version., in binary form. 2) tar bzip the tree. 3) repeat 1-2 for the latest versions of 4 major distribs (RH, SUSE, MDK, DEB testing or unstable) 4) repeat 1-3 for each new gnucash dev. version. release as a sort of "permanent alpha/beta" status package. (i.e. for devs only)
Posted Aug 12, 2003 12:59 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Thank god for Debian.
Posted Aug 12, 2003 14:35 UTC (Tue)
by leonbrooks (guest, #1494)
[Link]
Posted Aug 12, 2003 14:32 UTC (Tue)
by leonbrooks (guest, #1494)
[Link] (1 responses)
Posted Aug 12, 2003 14:33 UTC (Tue)
by leonbrooks (guest, #1494)
[Link]
Posted Aug 13, 2003 14:45 UTC (Wed)
by ghmitch (guest, #14012)
[Link]
I have been following GnuCash for several years now, and have to say that the visible progress has been spectacular.
State of the GnuCash project
GnuCash developers set themselves an ambitious set of goals, and delivered.
This is a magnificent application, and a pleasure to use, even if the baroque dependency set can make installation ... ummm ... interesting, at times.
For many, GnuCash replaced the last absolutely vital Windows application, removing the last barrier to adopting GNU/Linux as one's exclusive desktop environment.
This is an extremely important project. Anyone who can contribute should.
At one time, Intuit stated they would port Quicken to Linux. Obviously this has not happened. But, both Crossover and VMware can be used to run Quicken. They big problem I had with gnucash was the inability to download financial data from institutions.
State of the GnuCash project
GnuCash is an important project, and I wish them the very best.
However, speaking as a potential home user, there are two major
weaknesses with the current GnuCash. Basically, it lacks support for:
Missing functionality holding them back: Budgeting and Export
They might also consider a Microsoft Windows port, which I'll explain in
a moment.
Well are there programmers who are familiar with how a budget is done?
Missing functionality holding them back: Budgeting and Export
Well, QIF export should happen thru LibOfx before the end of the year.Missing functionality holding them back: Budgeting and Export
... GnuCash is written partly in Scheme. Need I say more?One reason manpower is short...
Scheme is a fine language, but it's not mainstream, and
choosing Scheme artificially restricted the pool of
available programmers. The GnuCash crew has in the past
denied that choosing Scheme would cause any trouble,
but I'm not sure they can deny that now.
No. Scheme was the right choice. They are following in the footsteps of the GIMP and other fine applications by embedding Guile. They just need to document the Scheme API a bit better. You want to write a report? It's easy, just whip up a scheme function; it eliminates the need for complex module loading code; the Scheme VM does the code loading for you.One reason manpower is short...
... and Gimp is backpedalling furiously from that decision;One reason manpower is short...
they now allow plugins in C, Perl, and Python as well as
the original Scheme. Looking at the
registry of available plugins at http://registry.gimp.org,
it seems clear that a lot of plugins are being written in
Perl and C.
the ass, and I'm a fairly good programmer. The documentation sucked,
and Scheme was a bit of a nightmare to learn on the fly. I'm
sure if I had already known Scheme, it would have been a lot
easier. But next time I do it, I sure as heck won't use the Scheme
interface.
I respectfully disagree. Note that I am not disparaging scheme in any way. One reason manpower is short...
I am also not denying that Scheme may be a good choice for Gnucash. I use GnuCash every day despite having some issues with it's UI and performance, so the choice can't be all that bad ;-). However, I agree that Scheme *is* the main reason for lack for developers. It's simply not a mainstream language.
programming. However I never got around to doing serious programming
in Lisp or Scheme. On the other hand I have written decent sized programs
in C/C++/Java/Perl/Python. I have contributed to a few open source projects. I even have a patch for gnucash for supporting Indian mutual funds - but that's a patch for C code in gnucash. You may not like my attitude, but hey, that's the reality. I am sure a lot of developers share this view.
It is weird how someone who has written "decent sized programsOne reason manpower is short...
in C/C++/Java/Perl/Python" should have problems with Scheme.
I don't understand this - Scheme is a very simple language
- much simpler than Perl, certainly.
Scheme is not, even though Scheme is much more mainstream
when it comes to the history and development of
programming languages.
of nested lambdas that may be harder to understand for most people
(including myself), but I assume GnuCash doesn't do that.
> It is weird how someone who has written "decent sized programsOne reason manpower is short...
> in C/C++/Java/Perl/Python" should have problems with Scheme.
> I don't understand this - Scheme is a very simple language
> - much simpler than Perl, certainly.
Programming course for my under graduate degree and have done some
simple Emacs Lisp programming. I never did any serious programming
with Lisp/Scheme in my professional career though.
> Scheme is not, even though Scheme is much more mainstream
> when it comes to the history and development of
> programming languages.
Syntax is syntax for most languages...LISP style not readable
Most programmers can sit down and read code examples and pick up
the syntax of the language. Some quick testing, writing examples,
modifying code and you got the basic idea.
arbitrary changes to see what if. To many "gotchas" especially with the nesting of the braces.
There's been a lot of stuff I've wanted to contribute to GnuCash, but frankly, even compiling the thing is a PITA which can take days on a clean-installed LFS (linuxfromscratch.org) system, and can break stuff on a "proper" Linux distro.State of the GnuCash project
2) Identify the reasons for these dependencies,
3) After (2), review if a broader scope is possible (eg, exactly which versions of guppi can be used?)
4) After (2), review which dependencies are required for which features
5) Accurately ist the dependencies by feature
6) Document (4).
7) Fix the configure script so users can build without the entire dependency list available if they do not require the specified features
8) Document accurate and readable build instructions with useful explanations (the LinuxFromScratch.org project's quality of documentation should be used as a minimum target for this)
9) Publicise GnuCash among Linux users, and the need for developers
10) Take time out to clean up the code as identified in (2-8). Target should be to install with a standard GNOME 2.x (ideally 1.4+ also) installation as identified by GNOME. This should take priority over feature-creep, and may even involve removing features.
11) Repeat (9)
12) Success!
Exactly. The Dependancy-Hell has been the sole factor stopping me personally from contributing to Gnucash. I actually tried. Twice. I started by doing the same thing I would do with any project where I want to contribute:State of the GnuCash project
* Half of those are not in the standard distros.
* A few of those must be one spesific version (not older, not newer)
* Installing that spesific version would blow up other software that depends on a newer version.
* Installing /both/ the older and the newer version migth in principle work, but is a chore.
Whoa, that's a lot of design changes just b/c of release constraints !why not solve the dep. problem once ?
plus, perhaps, a small scriptlet to source for the environment vars.
In other words, I view the compilation problems as more of a distribution difficulty (as in distributing to the client, not as in lin. dist.) than as a design defect. The solution should be in that direction.
You don't need to do it for Debian. apt-get install gnucash has always worked for me. I'm upgrading from 1.6 to 1.8 right now. Sure, apt needed to upgrade 13 other packages, but hey. I don't have to think about!why not solve the dep. problem once ?
"urpmi --auto-select" gets latest versions and all necessary dependencies plus URPMI's the same
knock-on dependencies.
guile >= 1.4-11mdk Dependencies: binary (from Mandrake 9.1 / GnuCash 1.67)
umb-scheme >= 3.2-17mdk
Guppi
libghttp1
g-wrap >= 1.1.10
python >= 2.2
libICE.so.6
libIIOP.so.0
libORBit.so.0
libORBitCosNaming.so.0
libORBitutil.so.0
libSM.so.6
libX11.so.6
libXext.so.6
libXi.so.6
libart_lgpl.so.2
libaudiofile.so.0
libbonobo-print.so.2
libbonobo.so.2
libbonobox.so.2
libc.so.6
libdb.so.2
libdl.so.2
libesd.so.0
libfreetype.so.6
libg-wrap-runtime-guile.so.2
libgal.so.19
libgconf-1.so.1
libgconf-gtk-1.so.1
libgdk-1.2.so.0
libgdk_imlib.so.1
libgdk_pixbuf.so.2
libghttp.so.1
libglade-gnome.so.0
libglade.so.0
libglib-1.2.so.0
libgmodule-1.2.so.0
libgncengine.so.1
libgnome.so.32
libgnomecanvaspixbuf.so.1
libgnomeprint.so.15
libgnomesupport.so.0
libgnomeui.so.32
libgtk-1.2.so.0
libgtkhtml.so.20
libguile.so.9
libguppi.so.16
libguppitank.so.16
libm.so.6
liboaf.so.0
libpopt.so.0
libutil.so.1
libxml.so.1
libz.so.1
libzvt.so.2
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.2)
libdb.so.2(GLIBC_2.0)
libm.so.6(GLIBC_2.0)
gnucash = 1.6.7 Dependencies: gnucash-devel (from Mandrake 9.1 / GnuCash 1.67)
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
ld-linux.so.2
libc.so.6
libdl.so.2
libglib-1.2.so.0
libgncengine.so.1
libm.so.6
libpopt.so.0
libxml.so.1
libz.so.1
libc.so.6(GLIBC_2.0)
...but from memory, there was an item or two missing from this.
One question. Has the GnuCash project ever considered looking for a commercial sponsor/benefactor? I just might be possible that some small business software integrator might be interested enough in a commodity 'Quick Books' type solution for small business to lend a hand. Have their been any contacts with Ximian to explore possible opportunities in this direction?
State of the GnuCash project