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

Hi;

On Fri, Jul 15, 2016 at 11:16 AM, Erik Huelsmann <..hidden..> wrote:

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.

Well, ideally we have something that works flawlessly for one thing and pretty close to working for the next.

Also I think it would be easier, not harder, to get a good user experience if we have a few solid pieces first as well.

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?

To be honest, my thinking is that when we get the AR and AP transactions ported over, thats when I think we will get new developers. But I think there may be a few users that could really use a dedicated GL app that interfaces nicely with other systems.

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.

I don't expect it to be a lot of effort long-run because effectively we are talking about a subset fo the application with its own test runs etc.

That being said, i wonder if it would be better to phrase this as:

Assuming someone finds this worth doing, is this something we want to support as a project? One thing I have learned is that volunteering other people's time in open source is really not a good idea.

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?

My thinking is:

1. GL entry, reports, and financial statements to start (the financial statements would have to be ported, or some of the old db structures left in for compatibility - I am not actually adverse to initially just including the whole same db schema for ease of migration and management).

2. We could, optionally, include contact management though then that starts to feel like two different applications

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?

Right.

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

There are two areas where this could be an important addition though, following on John's important points in response as well.

It's really really hard to talk about what kind of API we want and what kind of user experience we want when the rewriting effort is so large that by the time we get even close, what is modern will be ancient.

I guess my thinking is that if we have just a gl and financial reporting package (with more to be added later) it becomes an easier discussion piece.

But again, it is contingent on someone finding the time and value in doing the work. One of my assumptions is that if people find it valuable they will find time to help out. If not, it won't get done.

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.

Agreed on this.

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.

Agreed here too.

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?)

Agreed. So a question is:

does having a version without the old code where we can talk about these without immediate legacy concerns help or hurt?

Moreover, would having something we could point to as the approach of the future of the project be helpful or harmful?

I don't know whether this is helpful but I think at present it shouldn't be to the detriment of our current approach.

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.

------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more