Re: PEAR's mission statement - let the fun begin

On 2006 10 15 04:35, Ian Warner wrote:

Christian Weiske wrote:

Daniel and Ian,

To get code into PEAR, it has to run a gauntlet of picky, fussy developers who will be against a package going into pear for very minor deviations from coding style. PEAR should be more 'open', and relax standards in terms of getting packages in

What I like at PEAR is that there actually are coding standards, and the (even if light) enforcement to document your code. I really appreciate that code in PEAR isn't some hackety-hacked-files that are unmaintainable, but you really have a base you can work with.

I think PEAR should concentrate on some niche packages also - i.e. Web Services is a good example. So instead of waiting for proposals a list of all the possible Web services should be gathered and then a call for developers to code these.

That's the wrong approach in my eyes. I develop and put code into PEAR because I actually need it, and not because someone out there needs it and not me. That is what paid work is for.

I am sure though that there are hundreds of developers around the world doing a Google / Amazon web service or something. Having something in PEAR to say Hey code it here, and some pointers /comments / discussion on what direction to take may mean that these developers come to PEAR and code it within these confines, the benefits are a community of 'experts' who can help and critique, plus a community of users who will bug fix with you. If no one wants to code the package then fine it stays listed as unmaintained - people can still though comment (hopefully this feature will be added) on these. But what I am trying to do from my suggestion is get people interested in developing with PEAR to say that a package is already passed the proposal stage cause we feel we need it.

Ian has nailed this one exactly: I'm sitting here with an XML-RPC library that has evolved from a very basic library I found a few years back into one that has more and different capabilities from XML_RPC2. If I had known XML_RPC2 was "in the pipe" I could have spent my effort on it instead, and we all would have had a more capable package (RPC2 has stuff that's not in my library as well). As Christian points out, I built my code because I needed it. But I could have done it faster, more reliably, and given some of my effort back to the community if one of my many searches on the subject had led me to PEAR. Instead I get the much more difficult task of trying to figure out if I can find a way to merge my features into RPC2 and find a way to wrap it in a way that makes it compatible with my API. Yuck.

I think the point of Daniels email and what I read into it was that to get a proposal through was EASY - to get the proposal passed as STABLE is going to be tough, ie this is when CS and practices come under scrutiny, users of PEAR should be warned maybe that if the package is not stable then it may not live up to there expectations, but this goes without saying in most cases as the package would state Beta or Alpha. I like this idea a lot, as it will provide a means for collaboration at the early stages. I am taking it one further and saying let PEAR propose the package and get collaboration within the PEAR developers working at stage alpha, and get the base that you mentioned sorted. Some useful tips on how to write a mission statement can be found here - http://framework.zend.com/roadmap Send also have a package WANTS section, similar to what I am saying.