--- On Thu, 1/20/11, David E Jones <d...@me.com> wrote:
> On Jan 20, 2011, at 11:08 PM, Adrian Crum wrote:
>
> > --- On Thu, 1/20/11, David E Jones <d...@me.com>
> wrote:
> >> On Jan 20, 2011, at 10:52 PM, Adrian Crum wrote:
> >>
> >>> Two new projects were started - OpenTaps and
> Moqui.
> >>>
> >>> Speaking personally (and I stress personally -
> I'm not
> >> speaking on behalf of the OFBiz community) that
> sort of
> >> thing is counter-productive. I know the authors of
> both of
> >> those projects and I consider them friends. I'm
> also very
> >> familiar with the projects themselves.
> >>>
> >>> It's easy to just scrap existing code (or an
> >> established community) in frustration and start
> another
> >> project. It's hard to find a migration path that
> continues
> >> to embrace new technologies without causing undue
> hardship
> >> on the existing installed base.
> >>>
> >>> It would be better if we could find a middle
> ground -
> >> a compromise - that keeps the talent and
> innovation in a
> >> single project, instead of scattering it into
> competing
> >> projects.
> >>
> >> Do you really think that is the best idea? Isn't
> one of the
> >> problems with OFBiz that everything is in one big
> pot, but
> >> not all users want the same thing, and so there
> are constant
> >> fights about what should go into the single pot?
> >>
> >> Maybe it would be better if there were a stable
> framework
> >> and a bunch of separate "pots" sitting on top of
> it that
> >> address different audiences and are driven by
> different
> >> groups with different needs/wants? That would
> apply to
> >> different themes, different UIs, different
> business domains,
> >> etc.
> >
> > That sounds wonderful! Why not do it in a project that
> has been around for 10 years and has a considerable user
> base and developer base?
> >
> > OFBiz and your vision are not mutually exclusive.
>
> In a way they are. The whole point is to not have anything
> like a single project. There would be a framework project,
> and a data model project, and then everything else (themes,
> applications, reusable elements for use in applications,
> etc, etc) would all be separate projects.
>
> The point is to grow an ecosystem on a strong foundation
> and encourage people to do there own thing in separate
> projects that easily work with others built on the same
> foundation.
>
> The point is to avoid the "Tragedy of the Commons"
> (http://en.wikipedia.org/wiki/Tragedy_of_the_commons),
> which is something that OFBiz suffers from a lot and without
> splitting the project into dozens of small parts I don't
> think it can be avoided. The mentality of going to one place
> to get everything I need or want is just not realistic and
> results in the tragedy of the commons.
We have common goals, but two different approaches. Your approach is to scrap
everything and start over. My approach is to bundle up pieces of OFBiz into
"pots" that can be spun off into separate projects (ie. conversion framework,
temporal expressions). For example, I have a project I'm working on now that
desperately needs a stand-alone entity engine - but the existing OFBiz entity
engine code is too tangled with everything else. The service engine could be
bundled up as a separate project and maybe run on JMS - so it can be integrated
with third-party applications.
>From my perspective, OFBiz contains valuable technologies that could be spun
>off into separate projects. We just need to think of it more as a collection
>of libraries. I believe that approach would be far more constructive than
>having other projects competing with OFBiz.
-Adrian
