Overlay approach

There seems to be two main approaches to developing PEAR (forgive me if misinterpret Eric Raymond's dichotomy): The cathedral approach: > >style and stick with it. PEAR is an attempt to get a unified set of > >classes written in a unified manner with consistent documentation and > >predictable naming, etc. Many people have asked for this, so that is what > >were are providing. The bazaar approach: > The way I see it your greatest problem is that you still miss the point > that community could grow larger if you started assuming that each > individual has ego that must be valued to be encouraged. You should be > thankful for the contributions that people make instead of discarding those > that are willing to participate. I think that both approaches have merit. I like to have a consistent development library to work with, on the other hand I think PEAR will scale about 10 to 100x faster if it is made more accessible to the general PHP development community. Personally, I think we can have both. As the bionic man used to say, "we have the technology". Here are some ideas: What about creating an index of the code base as a previous poster (Jon Parise) has suggested. I would, however, suggest that we create a dynamic index, one that allows users to apply filters to the index. The filter might have an option called PEAR CORE, which would be code contributed by the current PEAR CORE team. When the user browses this index they only see code that has been contributed by the PEAR CORE team. If they also selected the PEAR SKIN (to extend the metaphor) filter, they could see all the contributed code. Other filters might include view popularity, download popularity, recency, author(s), available documentation, PEAR standards compliance, user voting, etc... On the uploading side, I think the PEAR CORE team might still use CVS to manage the tree, however, I think PEAR SKIN contributors could use a web based contribution system something like PHP Classes. There are alot of potential contributors who have no desire to learn CVS, especially if they come from the Windows or Mac side of the world or if they just don't see the value given the modest nature of the code they are contributing. An additional feature that might be nice would be to create dynamic PEAR distributions based on some of the above-mentioned filters. The user might also be able to exclude code by clicking on a checkbox as they notice warts on the PEAR SKIN. It would also be nice if the PEAR TREE remembered their preferences so that 1) they could more easily upgrade their personal distributions in the future, and 2) collaborative filtering could be used to construct a semi-authoritative mixed distribution that consisted of the PEAR CORE and parts of the PEAR SKIN that proved to be popular as measured by indicated preferences of multiple downloaders. I suspect that the system that Manual Lemos has developed to manage the PHP Classes repository could be extended to do something like this. There is nothing stopping Mr Lemos from doing this? I think he would have the killer PHP code distribution site if he did. The main economic model driving the major Linux based companies in the early days was the killer distribution. Everybody seems to benefit from this model. I think an overlay-based browse and distribution model could address most of the conflicting viewpoints cited above. Regards, Paul Meagher