LWN: Comments on "State of the GnuCash project"

LISP style not readable

Dareth — Tue, 26 Aug 2003 15:46:15 +0000

Syntax is syntax for most languages...

Pascal,C,Java, hell even Perl.

Lisp just doesn't fit the normal mold.
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.

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
arbitrary changes to see what if. To many "gotchas" especially with the nesting of the braces.

The comments are helpful.. but some heavy tutorials will be needed to get coders past the initial "WTF kind of code is this!" reaction.

State of the GnuCash project

ghmitch — Wed, 13 Aug 2003 14:45:55 +0000

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?

One reason manpower is short...

rganesan — Wed, 13 Aug 2003 05:29:11 +0000

> It is weird how someone who has written "decent sized programs
> 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.

I didn't say I had problems with Scheme. I had taken a Lisp
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.

> It is also strange how Perl/Python are viewed as "mainstream" but
> Scheme is not, even though Scheme is much more mainstream
> when it comes to the history and development of
> programming languages.

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.

URPMI's the same

leonbrooks — Tue, 12 Aug 2003 14:35:50 +0000

"urpmi --auto-select" gets latest versions and all necessary dependencies plus
knock-on dependencies.

Dependencies: gnucash-devel (from Mandrake 9.1 / GnuCash 1.67)

leonbrooks — Tue, 12 Aug 2003 14:33:57 +0000

gnucash = 1.6.7
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.

Dependencies: binary (from Mandrake 9.1 / GnuCash 1.67)

leonbrooks — Tue, 12 Aug 2003 14:32:06 +0000

guile >= 1.4-11mdk
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)

why not solve the dep. problem once ?

kleptog — Tue, 12 Aug 2003 12:59:02 +0000

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!

Thank god for Debian.

One reason manpower is short...

Per_Bothner — Tue, 12 Aug 2003 12:02:07 +0000

It is weird how someone who has written "decent sized programs
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.

It is also strange how Perl/Python are viewed as "mainstream" but
Scheme is not, even though Scheme is much more mainstream
when it comes to the history and development of
programming languages.

Now there are styles of Scheme programming with heavy use
of nested lambdas that may be harder to understand for most people
(including myself), but I assume GnuCash doesn't do that.

why not solve the dep. problem once ?

guybar — Tue, 12 Aug 2003 10:31:20 +0000

Whoa, that's a lot of design changes just b/c of release constraints !

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.
plus, perhaps, a small scriptlet to source for the environment vars.

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)

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.

State of the GnuCash project

ekj — Tue, 12 Aug 2003 07:20:44 +0000

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:

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

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.

One reason manpower is short...

rganesan — Tue, 12 Aug 2003 05:56:58 +0000

I respectfully disagree. Note that I am not disparaging scheme in any way.
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.

I like Lisp and it's variants, I've even tried my hand at some Emacs Lisp
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.

One reason manpower is short...

dank — Tue, 12 Aug 2003 01:39:39 +0000

... and Gimp is backpedalling furiously from that decision;
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.

I wrote a little plugin once for Gimp in Scheme. It was a major pain in
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.

State of the GnuCash project

stevep — Tue, 12 Aug 2003 01:06:38 +0000

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.

What the GnuCash team need to do to attract developers is:

1) Identify dependencies (including min and max version numbers)
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!

One reason manpower is short...

roskegg — Mon, 11 Aug 2003 23:49:35 +0000

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.

I am suprised they hang on irc.gnome.net instead of irc.gnu.org. That might help a bit.

One reason manpower is short...

dank — Mon, 11 Aug 2003 22:43:55 +0000

... GnuCash is written partly in Scheme. Need I say more?
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.

Missing functionality holding them back: Budgeting and Export

benoitg — Mon, 11 Aug 2003 19:56:45 +0000

Well, QIF export should happen thru LibOfx before the end of the year.

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.

Missing functionality holding them back: Budgeting and Export

smoogen — Mon, 11 Aug 2003 19:12:19 +0000

Well are there programmers who are familiar with how a budget is done?

Missing functionality holding them back: Budgeting and Export

dwheeler — Mon, 11 Aug 2003 18:48:19 +0000

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:

budgeting (input budget, compare/graph vs. actuals), and
data export (as so-called "Quicken" files).

They might also consider a Microsoft Windows port, which I'll explain in a moment.

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

State of the GnuCash project

freelsjd — Mon, 11 Aug 2003 16:43:32 +0000

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

jre — Mon, 11 Aug 2003 16:39:13 +0000

I have been following GnuCash for several years now, and have to say that the visible progress has been spectacular.
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.