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
