cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Supported and unsupported blocks
Date Wed, 16 Mar 2005 09:58:34 GMT
Jeremy Quinn wrote:

>
> On 15 Mar 2005, at 09:14, Reinhard Poetz wrote:
>
>>
>> Where shall we draw the line between "supported" and "unsupported"? 
>> Is it really the "two committers rule" that I applied above?
>
>
> Don't get me wrong, I am happy you are being pro-active about this.
>
> However, I see several items on the "unsupported" list which are IMHO 
> important components of Cocoon, or are blocks that I use regularly in 
> my work. eg. chaperon, jms, naming, repository, webdav, xmldb (and 
> others). In most cases, the fact that they do not currently have >2 
> supporters does not effect their quality and usefulness.

It is not about quality and usefulness it is about the degree of 
community support.You probably remember Stefano's various discussions 
about open source dynamics. One of his main messages, as I understod it, 
is that "it's all about coomunity". Software that attracts community 
will sooner or later achieve high quality and usefulness and also adapt 
to changes in use patterns and development in the world outside, while 
software that don't attract community will not adapt to a changing world.

A common complaint about Cocoon is that it is "big, complicated, scary 
beast" 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=110327845301789&w=2 and 
one of the reasons for that is the percieved lack of focus. For someone 
who hasnĀ“t followed dev-list closely it can be quite hard to evaluate 
what Cocoon is and decide what parts that are safe bets to depend on.

Depending on a block that has support from some committers mean that you 
have much larger chance to get answers if you ask something and it also 
means that you have much larger chance to get your patches applied. In 
short community support it is a very important factor when you evaluate 
the techical risk in your project. IMO we should take responsibillity 
and give users an realistic idea about the actual level of community 
support.

Focus is about choosing and it might be painful, but giving the users 
the impression that everything is equally important is really to 
complicte life for them. And for us it mean unnecessry duplication of 
effort and no coherence in the result. Chosing CForms as the forms 
framework is an excelent illustration on what happens when one get from 
one man show to community support.

> On reviewing this list again, I see several blocks that I have worked 
> on that I probably should have put my name to,

You didin't.

> and I notice several blocks that I know people actively care about, 
> that they have not put their name to.
>
> Maybe I misunderstand the purpose of having "supported" and 
> "unsupported" blocks, but I would hate to useful work being sidelined 
> by not attracting usage or new contributions.

That is of course a dissadvantage, but it should be compared to the 
frustration and lack of trust it creates for users to depend on blocks 
that are one man shows from people who not are around and support their 
work anymore.

                                                --- o0o ---

Taken togther IMO marking the block with >2 supporters as supported is a 
good and honest start. For the rest of the blocks, if anybody care 
enough it is just to motivate why the block should be marked as 
supported and start a vote about it.

/Daniel


Mime
View raw message