santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: XML-Security TLP -> Santuario
Date Thu, 22 Jun 2006 19:05:58 GMT
On Jun 22, 2006, at 3:01 AM, Berin Lautenbach wrote:

> Roy T. Fielding wrote:
>
>> It sounds like a decent idea for a federation, but a terrible idea
>> for a project.  Projects need to be responsible for a product or they
>> just end up in the weeds.  A federation of projects can simply  
>> maintain
>> a general mailing list and website.
>
> It would be responsible for code - the current xml-security stuff that
> sits within the XML project/federation.  And it would look to start  
> new
> things as well - with an absolute intent to move them to TLP when
> necessary (i.e. when it became clear the Santuario PMC did not have
> direct oversite).
>
> I know we are trying not to create umbrella projects - I'm trying to
> walk a middle ground to see if we can make something like this work  
> with
> a community that fosters this area.  It's a bit of a community
> experiment as well as a technical one.

There is no middle ground.  I'll try to explain the problem.

When a project "owns" a category, such as security, the participants
think that they are responsible for all Apache products in that space.
Meanwhile, what they are actually working on is a fairly small project
that addresses the specific requirements of a given set of users, such
as xml-security.  People don't try to make products that are applicable
to every possible consumer in a given category, and volunteers cannot
oversee projects in which they do not actually participate.  What is
left is either a single project that rejects all new target audiences
or an umbrella project that creates an artificial barrier to oversight.

There is no way to broaden the perspective of a project -- people
simply don't wake up one day and discover a need to be aware of
everyone else's work in similar projects, and most people don't
have the bandwidth to do so anyway.  That is why each project has
to be self-governed.

When someone else comes along and says an obvious thing like
"XML is inherently non-secure, I want to work on a security project
that demonstrates a better way of securing blah", the developers in this
so-called "security" project are likely to be offended and make it
socially impossible for that person to participate.  Even if that
is not the case, the perception that it might be the case will cause
potential contributors to go elsewhere rather than express their
ideas for a new project.

The bureaucratic mentality of committees needs to be actively offset
by the board and the only real mechanism the board has to do that is
to make sure the committees don't own categories.  Instead, a PMC
owns a particular product-line and decides for that product-line the
design trade-offs to fit its target audience.  If someone else comes
along with a different audience in mind (but the same category), they
don't have to be compelled to merge with the existing project and we
don't have to abuse users with major incompatible changes -- we just
set up a new product line with its own set of developers.  If the
two projects decide to merge later on, everyone wins.  If not, nobody
loses.

Any given problem at Apache can be solved at least a dozen different
ways, satisfying different sets of consumers, and reaching independent
levels of perfections in the minds of their own designers.  We should
not fear internal competition.

A federation is simply an umbrella project with no significant
responsibilities of its own -- all of its projects report directly
to the board and simply view the federation as a communal thing.
I think XML and Jakarta should already fall into that category.
Starting one is just like starting a project, except that the
purpose is limited to community/commons like things and not actual
products.

....Roy

Mime
View raw message