On Sun, Jan 5, 2014 at 2:59 AM, Erik Huelsmann <[email protected]> wrote:
> Hi Chris,
>
> First of all, thanks for drawing up this outline.
>
> After we get 1.4 up and out the door, I am looking to see what we can do
>> to help get pieces of our code more ready for 2.0. Here are immediate
>> proposals I would like to make:
>>
>> 1. Break off the most obvious pieces of the db schema into Postgres
>> extensions and publish them on pgxn. These could be bundled with LedgerSMB
>> as well, but should be available to other apps as well.
>>
>> 2. Break off simple, mature functionality in Perl modules into CPAN
>> modules. This would focus on a stable API, better backwards compatibility,
>> etc.
>>
>
> As one of the benefits you list below (under point 1 for packaging
> impact), or at least that's how I read it, that if we do this, we can shoot
> these "libraries" onto CPAN and pgxn and forget about them - until we have
> major new requirements.
>
> Do I read that correctly? If so: have you thought of the issue of
> ownership? Ie. will these simply be spin-offs from our project, there for
> anybody to pick up and start developing in the direction they like? Or are
> we in some way still involved as a project or as individuals, in the
> development of these modules we - for now - so heavily depend on?
>
> Not that I'm against it; I'm just wondering. I know that e.g. the APR
> (Apache Portable Runtime) project has been broken out of Apache's HTTPD
> project and has been adopted by a number of other projects as their
> portability library. So, this *can* work. Just thinking how we're going to
> make ours work.
>
Good questions. Here is how I have largely assumed it would work (and also
some benefits/difficulties I may have glossed over):
The LedgerSMB project should probably be the primary vehicle of ownership
for some time. The db interface logic should probably be folded in there
for now as well. As other projects want to contribute, then we would have
a framework to bring them in and could explore ways of doing that. I
didn't do this with the PGObject::* stuff because I was re-engineering and
exploring this a bit and wasn't sure I wanted to bring everyone in yet. I
think those should be moved back under the project.
In addition, I think there is a significant difference between engineering
for our own project usage and engineering for everyone to use. The
PGObject::* was a good first step there. The interface is richer and more
functional, and it's better thought through than what I wrote before in
DBObject.
I am assuming long-run that we want to have all of our application exposed
to solid public API's and so I think the best way there is to look at what
parts we can really solidify, think through the interfaces, and move to
publish them. But formalizing that I think is helpful in the sense that we
can think through questions like "who would use this?" and "what is a good
interface for them to use?" which tend to get clossed over in the main
project.
>
> I would propose focusing on accounts storage and menu structures first,
>> and then maybe the contact management side. Once something is broken off,
>> I would like to try hard to maintain backwards compatibility so this should
>> only be for things which have become relatively stable in terms of base
>> functionality.
>>
>
> So far we made one small step on this road by putting up the code for the
> ORM/perl-postgresql mapper on CPAN. I've lost sight on that. Could you tell
> us if any other projects picked it up? What have the experiences been there?
>
None yet, but I haven't done a lot of outreach. I keep finding a few bugs
and oversights (because I now have higher expectations for the code). I
hope to start outreach soon after my next round of bugfixes.
>
>
>> Here are the impacts I could see for packagers:
>>
>> 1. Packagers might want to package the extensions and cpan modules
>> separately. One advantage to this is that if changes need to be made for
>> different Pg versions they can be. The nice thing is that aside from
>> bugfixes, it should be as simple as uploading once and then not having to
>> worry about it until a material change comes in terms of requirements (and
>> those would be minimized).
>>
>
> Ah. Reading this again, I'm thinking you meant that the "not having to
> worry" part was mainly directed at packagers, on the assumption that the
> code has a high maturity level and stability (ie, is rock solid).
>
Right. Or rather that it would reach that very quickly. Again, I would
recommend doing this on things that are relatively easy to make these
guarantees first.
>
> 2. These could still be bundled all together if they are seen as closely
>> tied, but it would affect final target paths.
>>
>
> As long as there are no other projects using these modules, it looks like
> that's a viable option if creating separate packages takes a considerable
> investment in time from packagers (even if only once).
>
Yep.
>
> As for licensing, I would like to propose the following:
>>
>> 1. Major integration points I would like to be licensed under terms
>> functionally identical to PostgreSQL (i.e. 2-clause BSD or similar). This
>> reduces questions of licensing that integrators may have. As we simplify
>> the Perl code and move more logic into the database, it seems to me that it
>> may be good to move more of these to a BSD or similar license. Note that
>> our current PHP classes are under such a license.
>>
>
> Given that GPL and BSD have the same effect in terms of hosted
> webapplications - combined with my personal preference for the BSD-like
> licenses - I'm all for this one. We'll need to be sure to create new work,
> not derived work if we want to change the license, I presume? Unless, of
> course, we can get the original author(s) to agree to relicense?
>
Ok, for 1.4 code, we're talking about stuff that's been rewritten at least
once or twice since 1.3. Most of it is just by me. And even the 1.4 code
is not really ready for this. We'd probably need to re-engineer, rethink,
etc. and by the end I don't think there would be non-trivial contributions.
So I don't see a major concern here.
The PGObject stuff is actually a case in point. There were a few other
contributors to the API etc. in DBObject, but with the interface redesign I
can safely say that PGObject is only partly derivative of DBObject, and
certainly not derivative of some of the API extensions contributed by
others (while those showed some shortcomings, the solutions were
different).
>
>
>> 2. Areas of complex business logic I think for the time-being should be
>> under the GPL2+. As long as client libraries are under more permissive
>> licenses I don't see anything we'd gain by making these more permissive.
>> As it is we currently have the issue that someone could fork and upgrade
>> the license and we'd either have to follow them or not merge anything back.
>> Some *very* generally applicable parts might do well to be released under
>> a BSD-style license (the menu system comes to mind) in the hope that other
>> open source projects may pick it up and contribute but I think they'd be a
>> small minority.
>>
>
> The issue you note here regarding "license upgrading" isn't one I have
> seen in practice. What I *have* seen in practice is that companies would
> develop their in-house extensions. However, that's still possible with
> GPL2+. But, since the more complex parts are essentially tied to the
> LedgerSMB application and the remainder of the application is GPL2+, I
> don't see how having some bits labeled BSD.
>
I don't see inhouse extensions as the issue. The larger concern is
"suppose someone wants to write a connector between an MPL-licensed
shopping cart and LedgerSMB and wants to distribute it." MPL is not GPL
compatible, so it would be easier if they can use some sort of license-safe
integration points. In practice we could always give our permission for
distribution but I think it's better to give blanket permissions to use the
software.
>
> The licensing ideas are guided by the idea that what we are really hoping
>> to bring to customers is not so much a web app or a web app framework but
>> an intelligent database which can be the center of the enterprise. From
>> this viewpoint what we are doing in Perl mostly is trying to create
>> interfaces for the database, while the major logic is in the database. If
>> folks want to use our API, I am happy for them to do so.
>>
>
> This is entirely in line with the view we've been expressing. I like it
> and I think that it fits the picture of modern IT much better. To me, this
> means that we'll be developing REST apis as well (which in turn allows our
> webapplication to become more AJAXy).
>
Right. Also I think we will see lines of SQL eclipse lines of Perl in 1.5
as it is, and the general trend is towards very light Perl modules wrapping
the db logic. Those ones of ours which have a lot of logic are actually
quite generally applicable though and might do well to be more liberally
licensed (Report.pm for example), but most modules that would be BSD
licensed are likely to be quite trivial.
--
Best Wishes,
Chris Travers
Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor
lock-in.
http://www.efficito.com/learn_more.shtml
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
