Re: Proposal for 1.6 and above: small new-code-only developer release

Hi Chris,

One of the difficulties we have had for a while is the ability for new developers to come in and contribute, in part because of the code quality of the older code layers (most particularly the SQL Ledger codebase but also our earlier work) One possibility would be to establish a parallel release that would only be new code. One reason we haven't done that is that right now, if we did this, we couldn't meet anyone's needs.

Thanks for bringing this up! It also very much relates (IMO) to the thread I started some time ago about a next-10-years vision (http://archive.ledgersmb.org/ledger-smb-devel/msg06409.html).

As we talked a bit about it between us, you know I have my concerns, detailed below. Let me start by stressing I think it's important to hear from others what their opinion is, because these are just *my* concerns; others may think very differently and I'd like to know about those opinions.

There's a rather fundamental question to be asked here, if you bring up the "on boarding of other developers", which might come down to a "chicken and egg problem": should we expect more developers to be joining the team? I mean, is there a group of developers out there that we expect to be able and willing to contribute to our accounting application?

It just so might happen to be that (apart from the fact that we were lucky to have 2 in the first 6 months of the year), there are extremely few devs who would love to work on LedgerSMB (or any other web-erp) instead of some hyped app.

And if such a group of developers were to exist, what would stir their interest in LedgerSMB instead of in, say, Odoo? Wouldn't having something that *almost* works be a better choice for a business to run their operations on? And from there, contribute to the further development of the application.

But I was thinking. With the current work regarding GL, maybe in 1.6 we could start with a parallel release which would include only fully re-engineered code.

I can see how that would an absolute relief :-) However, do we think we can attract new developers with it? I mean, looking at yourself: would you join a team with the perfect code base, even though you can't really use the product yet? Or would you join a team where you can use the product, but simply want it improved, because the code base has real problems?

Just to answer that question for myself: I needed an accounting&invoicing application, was already running SL and wanted to get off that, when I joined the team here. I guess I fall in the latter category.

In particular this would mean:

1 A more consistent set of dependencies
2. A more consistent codebase
3. Something we could point developers to and say "here is where you start."
4. Since the goal would be to get everyone on this version sooner or later, it would mean that this could prioritize next steps and functionality to move.

How much effort would you estimate this to be? I mean, the initial creation of such a release? I'm finding we're thin on resources as it is and the above sounds like spreading them even thinner.

Just to note: if you don't want old code in the code base, then if you take today's code base, you have to remove AR/AP/Timecards/Orders/RFQs; basically you'd even have to remove the GL entry code, but that's easily replaced with something more modern, I guess :-)

So, that would leave us with *only* GL entry and GL reports?

From a user-perspective: what would a user (potential contributor) gain by installing this version over the version which *does* have the old code, where this user simply does not use it?

Basically, from a development point of view, I've taken exactly this approach, btw: I've been working around the old code, putting a foundation in place which can replace the old code after we rip it out, without ever needing to touch the old code. In that sense, the existence of the old code in the code base hasn't bothered me much over the past year, other than that I have had to fix bugs in our old code, because people were running into problems.

The biggest problem I see is that 1.6 would feature a very minimal application of this sort. Basically gl and financial reports only. Maybe we could get contact management in but it woudn't be connected to anything. A goal could then be to get ar/ap transactions (i.e. service invoices by amount only) in by 1.7, and then start on parts, orders and invoices after that.

What do people think of this idea?

While I still want to know what others think, I personally see more in the direction that we've been working on over the past 2 years:

- Have good tools in place to assess UI stability

- Replace the UI with a Dojo UI

- Replace the supporting backend code with web-services

Because that way, we can offer our existing users a stable application and a stable migration path. For new users, we'll become more-and-more interesting as the web-services backend opens up the development of other front-end tools and automation. As for how close we are to work on this: I think we're *very* close: the work to assess UI stability has already started and is well under way (the BDD tests), while we have moved all basic widgets to Dojo and we have started to implement some of the more complex widgets as well: e.g. the individual invoice lines and the collection of invoice lines have already moved to custom (composed) Dojo widgets. Next steps are to move the document properties into an even higher-level composed widget, design and implement web-services fitting the invoice screen and hook those services to the UI buttons. In order to be able to achieve this, we need some rewiring on the Perl side though, as we discussed yesterday. But all in all, I think we're very close to reaping the benefits of moving to Dojo and implementing the BDD tests.

From a user perspective, especially one who is development-savvy, I'm very much missing a vision/design about and implementation of "extension points". Much more than that I'm missing "a clean code base". What I mean by that is: points for extensions/add-ons to hook into our application so as to provide additional functionality. Like the EU "IC" (intra-communautair) reports. If someone wanted to develop those, that person may need to register new menu entries, add buttons to screens, add stored procedures to the database, etc. In the 1.3/1.4 era, there were a few add-ons developed. Those distributed patch files to change screens. If we want to go forward (and I think we should want to) to provide an open structure for extensions and other hooks people may want/need to develop, I think we need a strategy and design on the topic of extensions/add-ons. *That* may attract additional developers, I'd expect.

I think we don't need to (or even should) delay working out a design on this topic so we can frame all future development.

As for removal of old code: I don't see that as a goal by itself. I see it simply as a means to move the LedgerSMB code base to a point where we can have a much better agility in bug-fixing, where we can be much more extensible and open to integration with surrounding systems.

A lot of this - I think - goes back to the basic questions:

1. What do we want to be and for who do we want to be that?

2. What makes our current developers interested in LedgerSMB and what does that mean for future direction(s)?

3. Do the answers to the above questions match the expectations of our current user base?

(and if not, how do we manage a transition?)

Summarizing: I think the way we go forward should be a combination of what our users need/expect and what we can deliver, where the code base is a result of that.

Now, I've thrown much more into the mix than a simple "should we publish two versions: the current one and a stipped down one", so I'd love to hear everybody's opinions, including yours, on this "somewhat" broader scope of the discussion.

Thanks again for bringing it up!

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.