Hi all,
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.
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.
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).
2. These could still be bundled all together if they are seen as closely
tied, but it would affect final target paths.
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.
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 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.
Anyway, thoughts?
--
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
