On Feb 17, 2006, at 10:12 PM, Noel J. Bergman wrote:
Considering that people have expressed the clear desire to develop
joint
work, an umbrella-style project housing multiple implementations of
the same
domain, although probably workable for a period while the
community's active
focus is on the joint solution, if persisted into the long term
usually
leads to a balkanized project that breaks up.
I always get nervous when people try to smash together to different
code bases. Each code base will have a different set of assumptions
and will be optimized for different environments and use cases.
Normally, I see this result in a huge frankenstein code base that
fits no one's needs, or results in a third code base which has yet
another different set of assumptions and is optimized for different
environments and use cases.
What's my point? If there are people in the community that want to
work on a code base which is optimized for their use cases we should
let them. If this leads to a project that later splits into several
top level projects, it is not a big deal and I would say not a "bad"
outcome. After all we have several very successful web frameworks at
apache, and smashing them together would benefit no one.
So please, leave the door open to the possibility that you get
contributors that are interested in only one of the input code bases.
The ASF has, as I noted on general@, no need to deal with independent
releases of the vendor products. For that matter, we couldn't care
less
about anyone's delivery schedules. Our releases occur when
determined by
our PMCs. Vendors may have their own schedules, but our focus is
building
an ASF project. If someone wants to do a release on their
schedule, they
are free to pull source code and use it in accordance with our
license.
+1 I don't care about vendor release schedules either.
I do care about the community's ability to get releases for code that
they are using. I personally, would like to see a release of all of
the BPEL code bases quickly so I and others can easily work on
integration into our projects. I certainly will be able to build the
code from source, but I don't want to force that on to the casual
developers of any of the projects I'd integrate the code into.
James mentioned that ServiceMix has some needs to work with
Sybase's code.
I am sure that no one, *especially James*, wants anyone to have the
impression that ServiceMix is trying to co-opt the direction of this
separate project. The Sybase code will be available for anyone,
including
ServiceMix, to use as necessary, so you should feel free to pursue
whatever
direction is jointly chosen by this community.
Now that this project is forming, I hope we can put aside our past
and form a healthy community. Implications such as this only hurt us.
Although many of us who have experience in messaging systems will
have input
to share, I would like to see Intalio, Sybase, and other process
experts
take the initial lead on illuminating the technical directions. I
am keen
to see the discussions between Alex, Bill, Ismael, Matthieu, Paul
Brown, et
al continue on the path that they have chosen. To echo what
Sanjiva has
said, I've seen very promising discussions, which I will actively
follow. I
also like Ismael's "goals" e-mail, to which I hope to see direct
responses.
+1000 I'd really like to know what the different input code based
used for assumptions, and what the target environments and use cases
were. Architecture diagrams are always good, but I never create them
my self :)
-dain
