[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future of LedgerSMB: Ideas and RFC
- Subject: Re: Future of LedgerSMB: Ideas and RFC
- From: Luke <..hidden..>
- Date: Wed, 18 May 2011 15:15:58 -0400 (EDT)
On Wed, 18 May 2011, John Locke wrote:
Thank you for all your hard work on LedgerSMB, I really appreciate the
time and effort you continue to put into it.
I hate to be a whiner here, but trying to work with LSMB 1.3 has been
frustrating. Stupid bugs on just about every action you try to do. Chris
does a great job of responding to them when you report them, and
accepting patches -- I see credits to half a dozen non-core contributors
in the commit log. But if Chris is doing all the work, it's hard to see
how this project is any more viable than SQL-Ledger, which I abandoned
The most common complaint I see is about installation. If the thing can
not be installed smoothly in a variety of situations and configurations,
nothing else matters.
Sour the user experience out the door, and nothing else will be
forgivable, and interest in even trying it will remain at a very low
Installation issues should be priority #1 for the first new beta release.
It may be harsh, but I have very little faith that 1.3 can actually make
it out the door, or if it does, that it will be something the users have
any great interest in. I have felt that way for over a year now. I had
started getting interested with the prospects for 2.0, but quickly lost
that when I realized that there was an insistence in putting out 1.3. It
has become slogware, despite all the good work that has been put into it.
Maybe that's our fault for not being more involved; maybe it's the core
team's for not letting the community be more involved. It certainly has
to relate to Chris being the only primary code developer. There's only so
much that one person can do.
> What needs to happen to LSMB is for it to open up more widely to
contributors. I would suggest moving the code development to github --
That suggestion has been made, again and again. There seems a certain
reluctance on the part of the core team. Maybe grounded, maybe not--I
don't know the reasons.
I think Chris's priorities are right on -- but the biggest problem with
#1 is that it's very painful to actually use 1.3 right now. It's a major
step back in functionality, with a few nice exceptions. If you don't
have some good developer knowledge available, you really can't use it in
production -- I'm finding I have to go into the database on a regular
basis to fix things. It's not ready for non-developers to use -- which
means it's hard to get the feedback from regular users to make it ready,
because there are very few developers who have businesses that need the
kind of accounting system LSMB provides, and are willing to put up with it.
That would be me. I need the functionality, but I'm also a single
individual, trying to run two businesses. I can devote a little time to
helping to debug my accounting system, yes, but when I don't believe in
the product, it's hard to get up any interest in bothering.
Especially when 1.2, while not perfect, works so reliably, and 1.3 offers
very little that I *need*.
> So I really think #2 is on target -- the few of us who do fit that
description -- developers with real accounting needs who are willing to
put up with unstable/broken releases and contribute fixes -- need to be
drawn more into the community, not ignored until they go away.
If there is no excitement among the development types that this is a
product that will actually see a release, work, and be useful, not as just
an intermediate step, how can they build interest in the wider community
of users, who just want something that works?
(I do not claim to be a developer, having never contributed code other
than in templates, and that minor)
If Erik, Luke, Lyle, Jeff, David Mora, Lacey, Alexey and anyone else who
is contributing on a regular basis were recruited to the core team and
Let us not forget Armaghan Saqib, one of the most obvious choices for
recruitment to the core team (assuming interest).