On Dec 28, 2006, at 2:06 AM, Torsten Schlabach wrote:
Have you thought about not having releases of the whole package at
a time, but releasing components. You could version the framework,
the "execution environment" so to say and then version the indidual
modules (Marketing, Partners, ...). That would allow for a user to
upgrade what he needs to upgrade. You should still use some Linux
package maintainance system as a guide how to manage compatibility,
basically how to do SCM in the original sense of the word.
So I could find out, that in my installation I am running:
OFBiz Base: 1.0.12
OFBiz CRM: 1.1.3
OFBiz Accounting: 1.0.0
Now the team which is maintaining the accounting module feels like
releasing version 1.1.0 which still requires OFBiz Base 1.0.5 or
higher. I have 1.0.12, so I should be ok.
Next month, you might have a release of CRM which is 2.0.1 because
is has made a major leap forward in functionality. For that to
happen, you had to update the Base framework as well. So CRM 2.0.1
requires at least OFBiz Base 1.1.0. Get the idea?
This has been discussed a number of times and I am 100% against it at
this point. If we had 100 developers and we were trying to figure out
how to keep everything moving smoothly this might be okay, assuming
about 10 of those 100 developers contributing on a regular basis were
doing package management, then maybe.
Personally, the library management in Linux is one thing I HATE HATE
HATE about it. It makes the system a nightmare and sometimes because
there are system level libraries you have to do super-funky stuff to
get 2 different programs that require different versions of non-
backward compatible libraries to run together...
We may very well start versioning the framework separately at some
point in the future, and you can already run the framework without
the applications (just delete the applications and specialpurpose
directories). Totally separating them would mean moving the
applications to somewhere else in SVN and including the built
framework but not the code of the framework with the applications (in
SVN anyway).
Splitting out each component to have a different version number: I'll
fight that pretty hard because I think it would just waste a bunch of
effort and eventually fail. I don't think it would bring down the
project, but it would kill progress on various things for a while...
IMO the key to success of OFBiz will be to make sure you have
enough sub-communities which are going to focus on vertical
functionality as well as on locales. But keep them on apache.org
and by all means avoid a situation where a "basic OFBiz" is real
OSS but to really use it in a business, you need the X, Y and Z
components which are 300 USD, 2500 USD and 400 USD per seat and
only work with an outdated version of the package itself. Or even
worse: You are not going to find any compatible versions of X, Y
and Z at all to even get them installed.
This kind of threading and pseudo-commercialization was and is a
massive road-block to the success of something like Compiere and
IMO OFBiz biggest opportunity is to just do better here.
Unfortunately we can't do ANYTHING about what other people decide to
build based on OFBiz and how they decide to distribute it. We aren't
in the business of doing things in a GPL way, and we want to
encourage commercial as well as open source derivative works. That is
very explicit in the Apache 2.0 license and in how OFBiz has been run
since the beginning.
Fortunately there aren't any forks of the base OFBiz code base, and I
think that is partially because of this openness. There are a few
derivatives where people have chosen to do them as open source (or
semi-open source with a GPL/commercial dual license), and these to
some extent do compete with functionality in OFBiz. That's their
choice unfortunately and can make things more confusing for
prospective users, but in general it's a healthy thing to build up
more around OFBiz.
-David
