Re: Is LSMB really suitable for the public?

[John Locke <..hidden..>]

Hi,

I think the answer to the question in the subject line is simply "not
yet." Many, many open source projects take a long time to mature. As
best I can tell, the core team has made some architectural changes that
are substantially different than SQL-Ledger, and it's taking time to
work out the bugs.

I too have been holding off on doing any upgrades (I'm currently running
LSMB 1.1.7 in production) due to the frequent problems and updates being
posted. That's mostly because I, too, have a lot of irons in the fire
and not enough time to spare some for the project -- yet. More comments
below...

Phil Rhoades wrote:
> On Tue, 2007-04-24 at 13:17 +1000, David Tangye wrote:
>
>   
>> Without prattling on about this any further, can I just ask/suggest that
>> the developers:
>>  1. Stop doing functionality extensions/improvements
>>  2. Get the basics right.
>>     
>
>
> Hear, hear.
>   
I think that's what they're trying to do with the 1.2 series--get the
basic functionality right, in a cleaned up architecture. I'm not seeing
much in the way of new features.

>>  3. Set up and adhere to a better more comprehensive system test
>> strategy, and stop releasing any further stuff in future until it is
>> properly tested.
>>
>> Yep.
>>
>>     
Sounds like an area where the project needs assistance. Any testers out
there with some time to put together some unit tests? Maybe we should
have a page on the web site for "how you can contribute" to recruit more
help.

>> I have held off migration from SL, because this trend of broken releases
>> is concerning me, and I am seeing no evidence of any attempt to control
>> releases properly. In fact I am seeing too much hackering here. This is
>> not the way to convince many people to jump into the software, because
>> there appears to be too much risk that it will keep breaking in future
>> releases, and I never back horses that keep breaking down.
>>     
>
>
> I have basically decided to wait for v1.3 but will that make it even
> more difficult to upgrade from SL v2.6.15?
>
>
>   
I'm waiting for a version of 1.2 that doesn't have any problems reported
within a couple days--that or a few hours to devote to the task. The 1.1
series seems to be more stable at this point.

>> If the purpose of this project is to build and accounting or ERP system
>> for I.T. folks, say so. Actually I raised the point months ago about
>> defining your target market/user base, and no-one really had much to say
>> about that. I therefore surmise that the target market is not clearly
>> defined, or else is implicitly 'us developers on behalf of our specific
>> customers, whom we set up anyway'.
>>     
I remember having a similar learning curve setting up SQL-Ledger years
back--it was the first time I had touched Postgres, or CPAN. There's
plenty of enterprise software out there you wouldn't turn loose on Joe
user, and LSMB I think competes much more in those arenas than with
Quickbooks/Peachtree/etc. LSMB is not something I sell to my clients of
1 or 2 employees, or even 5 or 8.

It clearly needs an IT person to install and manage. So does SQL-Ledger.
I would suggest that any web application should have someone
knowledgeable managing it, and doubly more so for financial applications.

As far as I'm concerned, LSMB is not stable--it's a development project
right now that is usable in production. Pick your production versions
carefully, and if you're going to use it, stay abreast of new
developments. But it's the best open source financial system available.

David, you bring up some valid points but remember this project is
barely 7 months old. It has already made major strides, has a positive,
helpful core team and community. Why don't we keep it that way?
Stability will come in time.

I think the most constructive part of your post was requesting a better
system test strategy. This is important for several reasons--not just
for software quality--but in an environment where LSMB may be used to
support financial controls, we need to have some way of verifying that
the software does what it's supposed to do. (this could also ferret out
the cash reporting bugs present in the code base...) Any ideas where to
start?

-- 
John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
http://www.freelock.com