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.
------------------------------------------------------------------------------
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
