Re: [SL] Trend analysis - additional development

[Luke <sl...@li...>]

On Sat, 7 Jun 2008, Michael Hasse wrote:

>     As things stand currently we believe LedgerSMB has a good team  
> but it will likely be a couple of years before we're willing to even  
> look at it due not only to switching cost but also because the  

At the moment at least, there is an extant upgrade path from one to the 
other.  Don't know how long that will last, though.

> LedgerSMB team hasn't been around that long yet.  It's a similar  

As a team, no.  However, some of these guys have been in the accounting 
and database software, and open source software, arena for quite a while.
Keep in mind, that its main corporate sponsor at the moment seems to be 
the PostGreSQL company, and that is no shabby association of hackers.

> question - if the team falls apart, what are we looking at?  And is  
> it maintainable?

A good question, certainly.  We will have to wait and see when they get 
their 1.3 or 1.4 version released, how it is for new developers to get in 
on the action.

>     Similarly, if I have $20k-$40k to invest in a system, (tweaked or  
> from scratch), I don't just care about the immediate development  
> process, I also care about the longevity of support and the options  
> for same.  And we're not alone, we have clients that do DoD projects  
> having support contracts stretching into the decades.  They're not  
> using SL, but the concerns are the same on both sides of the fence...

I had one of those, in fact, who we did have using SL.  Everyone but the 
President hated it, because it was not more Quickbooks-like (it forced 
them to be aware of the riggers of the accounting process, and most of 
these people had a sales background).  However, for what we did, it was 
mostly usable (we had to customize various things, and do a lot of back 
end database work because of the lack of import features in 2.6), and 
completely stable.

That said, I am not likely to do that again (get a client with DOD 
contracts using SL), because of the same usability factors.  The main 
reason we did it in the first place, was that it had a usable web 
interface, and much of the access needs which were anticipated, were for 
users operating mobile wireless handhelds.

SL won hands down on that question alone, and so we took them there, some 
kicking and screaming.

Regards,

Luke