ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Ode / BPEL Donation of BPEL 2.0 Engine
Date Sat, 18 Feb 2006 16:04:20 GMT
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

Mime
View raw message