incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <m...@leosimons.com>
Subject Re: Outside view on incubator policy to initial committer list
Date Sat, 07 Oct 2006 07:33:56 GMT
On Oct 6, 2006, at 11:36 PM, Steve Vinoski wrote:
> Sorry, Leo, but I don't see the point of your message below making  
> statements about CXF that are wholly untrue.

The point was to provide some insight into the differences between  
different projects under incubation and how that leads to a different  
kind of incubation taking place. Also note that, to begin with, "the  
whole CXF thread" referred to a "whole" bunch of things that weren't  
really all about CXF at all, and just as much about the "general  
case". In this light, CXF is an unhappy example for a wider  
discussion, for which I'm sorry, but it tends to be somewhat  
difficult to avoid.

The fact that you consider what I said about CXF to be wholly untrue  
is probably since you (a) misinterpreted my statements, (b) you  
fundamentally disagree with my view on the SOA space and the  
assertions I made about it, and (c) you're missing some incubation  
terminology. I'm sorry, but it's probably not because I know nothing  
about middleware or SOA or CXF or incubation.

> First, CXF is corporate?

*sigh*. I said, "CXF was an attempt to start something by merging  
something corporate with something open source".

> That's incorrect, given that it's purely the combination of two  
> separate open source projects, Celtix and XFire. Celtix was  
> developed completely under the ObjectWeb community, and XFire was  
> developed under Codehaus.

When you look at the people (not the code), it is a combination of  
people from two open source projects, and some additional people. The  
project has quite a few committers who are paid to work on it. At  
least one company whose representatives I spoke with (IONA) has told  
me they plan to donate various other in-house things.

When you look at the project its stated goals, it is a combination of  
the goals from two open source projects, and some additional goals  
(the most obvious two being (a) becoming an Apache project and (b)  
merging two big existing open source codebases).

Various corporations have business strategies that involve CXF. Some  
of them but out corporate-oriented press releases or datasheets [1]  
which are, ehm, "itchy" from an apache-style open source perspective  
that say things like "Users who are interested in getting started can  
download Celtix 1.0 today at ObjectWeb, and developers who want to  
get involved in its next generation can contribute to the CeltiXfire  
project in the Apache Incubator" which is *just* enough off-key to be  
slighly annoying.

So, I do consider CXF a merge between something corporate and  
something open source. That isn't a bad thing in and of itself. It is  
just a difference (with wicket), and one that should be taken into  
account (when considering the incubation policies and processes).

For example, one project I've helped mentor, Harmony, did much the  
same thing -- it started with some donations from existing open  
source projects, some corporate ones, and it has various people paid  
by a few companies to work on it. Harmony still has a little bit of a  
corporate feel to it at times, but we've worked hard to shed as much  
of it as possible, hopefully to the point that the average CompSci  
student can start contributing and feel happy about it. The point is  
that this takes effort, effort which a project like wicket doesn't  
have to expend.

And even *if* you disagree that there's "corporate elements" to take  
into account here, I still suggest not calling CXF "purely the  
combination of two [projects]".

> Second, CXF is nothing but a bunch of buzzwords?

I didn't say CXF is nothing but a bunch of buzzwords. But contrast  
"SCA integration" with "built-in support for HTTP sessions" and  
you'll get the point.

I said "the stuff that CXF focusses on is still buzzword-ridden".  
There's so many of them that they get their own acronyms. SOA (has  
got to be my favorite), WS, ESB, etc. It's not CXF's fault (though  
I'd love an ASF project that would just do away with them all and be  
simple to understand to the rest of the world) this part of the  
technology space is not so good at explaining itself as it could be.

> I've personally been working for over 15 years now with numerous  
> people in various middleware communities on the technologies and  
> techniques that have led to what's going into CXF. Over the years  
> those communities have delivered a variety of commercial and open  
> source systems based on those techniques that run every single day,  
> often for years at a time, in production. I can assure you that  
> these approaches are quite far from being just buzzwords. You very  
> likely use such systems every single day, in fact, perhaps without  
> knowing it -- whenever you make a phone call or carry out a  
> financial transaction, for example. (Coincidentally, Mark Little,  
> one of the people directly affected by this whole issue, has done  
> tons of work in this area over the years as well.)

(which whole issue?). In any case, good for you guys. I didn't say  
that all the middleware work you guys (or anyone) have done through  
the ages is "just buzzwords", or that some of it doesn't "run every  
single day, often for years at a time, in production".

But I'll happily stick to my assertion that there's too many of them  
buzzy words (TLAs too, lots of TLAs), and that this is quite a  
reasonable indicator some people use to not touch these things even  
with a very long pole. It's not a beef with CXF, it's a beef with a  
whole technology space, and it is something that causes various  
problems for open source communities. For example, try explaining to  
your favorite ASF board member the difference and similarities  
between CX, XF, CXF, Axis1, Axis2, Synapse, Tuscany, and the-new-SOA- 
related-project-proposed-for-incubation-two-months from now, in 2  
minutes.

> Lastly, CXF has strong champions like Dan D. and Dan K. working on  
> it, along with some strong committers. I have no doubt they'll  
> continue to work with their mentors to make CXF a success.

Sorry, champion in incubator context is a specific term referring to  
a specific role taken on by a specific person - the original "old  
fart" at the ASF that helps a fledgling project with the first few  
phases of the project@apache. That project then alienating that very  
person a few months down the road is what causes the worry, since in  
a healthy situation that would be the last person you'd possibly  
alienate.

It is not the best word (read mail archives for why we stuck with it  
anyway), and it definitely isn't meant to imply other people are not  
to be considered "champions" in their own right. When you read  
"champion" on these mailing lists, think "specific incubator handyman  
person that takes care of some specific things".

cheers,

Leo

PS: the top posting doesn't make untwining these threads any easier...

[1] - http://www.iona.com/info/aboutus/collateral/CeltiXfire- 
datasheet.pdf

> On Oct 6, 2006, at 12:43 PM, Leo Simons wrote:
>> Hey Martijn,
>>
>> do keep sending these e-mails. Less replies doesn't mean that its  
>> less valuable.
>>
>> On Oct 3, 2006, at 9:38 PM, Martijn Dashorst wrote:
>>> Just to pose an outsider view, being new to the ASF and not to  
>>> hijack
>>> the discussion on the CFX/CeltiXFire, I would like to share my views
>>> on the policy of the incubator.
>>
>> I'm gonna respond in the generic rather than specific points.
>>
>> Rest assured, the whole CXF thread doesn't apply to projects like  
>> Wicket. Where wicket was a solid open source community already,  
>> CXF was an attempt to start something by merging something  
>> corporate with something open source, pour in some unknowns, and  
>> then hope for the best.
>>
>> Where wicket's technology space is essentially well-understood by  
>> most incubator PMC members (and asf peeps world wide, most  
>> likely), the stuff CXF focusses on is still buzzword-ridden and  
>> thus well-avoided by many.
>>
>> Do you really think a wicket contributor would've waited two  
>> months for his account if the people around him would've been  
>> happily committing code? Do you think you would've? I would guess  
>> board@ would've known about it by then, if not slashdot...
>>
>> ...It is simply a world of difference. Which makes writing a  
>> single, sane, understandable, clear, permanent, policy for both  
>> (well, n, there's a new world every time there's a new project)  
>> quite hard (I've never understood why we try, but that's another  
>> subject). For example, where I'll happily go and weigh what wicket  
>> contributors contributed to wicket before it came to apache  
>> (especially if those contributors rub my nose in it), I'm not  
>> gonna care a rat's ass what Joe Corporate Developer Who Is Unknown  
>> To Google Or Koders.com contributed to a corporate codebase before  
>> his company came to apache.
>>
>> Bluntly, a project like Wicket starts at 90% "community clearance  
>> done" (just some IRC things to convince people of ;) ), that other  
>> project starts at -20%-100% depending on which company it came from.
>>
>> In the end, this means you don't put your trust into the process.  
>> You put your trust into the people that make that process work,  
>> and into processes where what those people say and do (and vote)  
>> matters above and beyond most (some of it is legal shtuff, can  
>> vote all you like there, ain't gonna help) process description.
>>
>> Which, getting back to CXF, is now getting me really worried,  
>> since its champion and most active mentor resigned from his position.
>>
>> LSD


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message