Re: Future of LedgerSMB: Ideas and RFC

[Erik Huelsmann <..hidden..>]

Hi Chris,

Thanks for taking the time to write  down what your ideas are about
the future direction of the project! And thanks for your continued
support of the project too.

> Many of you may be frustrated at the pace of development of LedgerSMB
> and the fact that 1.3 has not yet been released. ÂDevelopment may
> appear to have slowed. Public discussions become less frequent...

>From where I stand - my interest in the project is only quite recent
[fourth quarter last year] - it looked like the project was slowed
down so much that it was not an option to actually start using the
software. It must be noted that I'm specially interested in the new
model for recording relations between people and companies to
interface data with other systems - a requirement next to support for
general accounting and AR management.

> For the last few years, LedgerSMB has achieved significant growth.
> Some of that growth has come at an organizational cost and for that I
> apologize to the community. ÂNow I have to try to help put the
> organizational stuff back together.

That's very good and encouraging news!

> In reality, far from being quiet, LedgerSMB 1.3 has had a huge amount
> of commissioned work done on it, not only for the core system (where
> the customer/vendor management, reconciliation, and payment interfaces
> have been completely rewritten) but also in areas of addons for fixed
> asset handling, template transactions, so forth. ÂWe have eliminated a
> lot of performance bottlenecks for larger databases, and provided a
> much higher level of security than previous versions. ÂThis has been a
> Âvery ambitious project and we are much better off for it.

>From other people's reactions I concluded it's not clear enough
"what's in it for them". In other words, in what ways does 1.3
actually contributes to the goals they may be trying to achieve.

Personally, being a new user for LedgerSMB, I'm missing documentation:
setup docs, but also admin docs, docs describing the roles of the
different modules, etc. Basically the information I need to asses
whether I may need to investigate a certain module before being able
to use LSMB for my business.

> I would like to propose a few specific directional approaches and get
> feedback from the community before proceeding.
>
> I think the major priorities at this point need to be:
> 1) ÂGetting 1.3 out the door.

To me, this means being able to develop using the customers model,
differentiating between companies and people. To John Locke this seems
to mean the a stable Reconciliation interface. What does this mean to
others?

Of all the people reading this list: what does "getting 1.3" mean to
you? Do you feel like it's an improvement? If so, why, or if not, why
not?

Reading the sneak preview description, 1.3 means (technically):

 * New customer architecture
 * Rewritten employee/HR module
 * Rewritten authorization/security
 * 4-eye principle
 * Rewritten bank reconciliation

I'd say these make up a nice list already, but maybe there's more,
which isn't on the 1.3 sneak peak page and hasn't been mentioned yet?
I can see why people would not upgrade immediately from 1.2 to 1.3 if
LSMB is working for them. That's only normal: I'm part of the
Subversion project and while 1.7 has been under development for 2
years now, there are still people using 1.4. However, that version
works for them. It's fine; no need to upgrade.

> 2) ÂFocusing heavily on community building
> 3) ÂTrying to build partnerships with other open source business
> projects (perhaps GNU Med and others?)
>
>
> To this end I would like to tentatively suggest the following:
> The first is a regular beta release schedule for 1.3... ÂMaybe every
> other Tuesday?

Are you sure? Aren't you going overboard a bit on the enthousiastic
side now? :-) I'm serious though: my experience is that creating a
release is generally more work than you think. You need to document
the changes since last time, create tar archives, create and send an
announcement, maybe update a project blog, etc. Easily takes all
afternoon. Time you can't spend fixing bugs or coaching co-developers
find their way around in the code base. For my own project, I'm using
a 2-month release interval. We're a project of 4 developers, with
differing levels of activity, just like LSMB.

> There are some committed fixes for 1.2 which have not made it into a
> release. ÂI would like to release this as soon as possible. ÂHowever,
> given the fact that bug reports have slowed, I think it is likely that
> it is not likely that 1.2 will see another release absent developing
> problems Âlike issues caused by new versions of Perl.
>
> I'd also like to encourage anyone who is interested in contributing to
> start looking heavily at 1.3. ÂThis is a place where you can earn a
> name in the CONTRIBUTORS file, or possibly even commit privileges.
>
> But in addition I would like to see what the community thinks. ÂWhat
> do you think we need to do to pull things back together and bring the
> project to the next level?

Well, I guess your priorities are good: find out what people think
needs to be fixed/stabilized before 1.3 is usable. For 1.4+ it's
probably a good idea to find a mode where releases get only big enough
to address a small number of specific issues (and the regular bug
fixes) on the point releases. That might satisfy only a small group of
current users, but the continued development could easily attract new
users too. That would be a net benefit.

My $0.02.

Bye,

Erik.