Re: candidates for PEAR Group: why should we vote for you? Tell us your plans and your history

On Wed, 2009-06-17 at 14:31 -0500, Greg Beaver wrote: > Hi, > > As we near the next election for PEAR Group and President, I'd like to > ask all of the candidates to provide us with a brief history of their > contributions to PEAR, and why we should vote for you. This year, the > content of what has happened is more important than in previous years > because Pyrus and PEAR2 will be happening as a reality in the next > couple of weeks. Hello PEAR developers, I have been contributing to PEAR since 2005 in the form of patches and bug reports. In 2007 I started working on package proposals and now am lead on the GPG, Akismet, PayPal SOAP and Amazon SQS packages. I've been a PHP developer since 2002. I am a proponent of the reusable component model, and appreciate the quality controls and coding standards implemented by PEAR. I am always available via email and often on IRC. I try my best to provide meaningful feedback for package proposals as I know the feedback of others has been invaluable for my own packages. As a member of the PEAR Group, I will continue to be active in the community. I enjoy writing documentation and will help with writing and maintaining I see several issues in PEAR that need to be improved: 1.) A lot of PEAR contains old and unmaintained PHP4 packages. This hurts the perception of PEAR. At silverorange, we used to groan every time we used PEAR because there was _always_ a bug in whatever we tried to use. I think many companies still perceive PEAR this way, even though PEAR has formed a QA team and implemented testing guidelines for new packages. 2.) PEAR is perceived as overly bureaucratic by many. There is value in a strict approval process, as it results in higher quality code. Still, the process of getting a package in PEAR is a difficult one for new developers. Having the website working smoothly and having responsive community members will go a long way towards making this better. 3.) CVS. No one likes CVS. The SVN migration needs to happen. 4.) PEAR is too hard to use. There are a lot of great packages in PEAR, but still many developers write their own, or use an equivalent package from another project. I think the reason is people can't figure out how to install PEAR packages. The command-line model is great for advanced users, but 90% of PHP developers just want to download, unzip a file and start using it. The majority of user questions on IRC are how to get the pear command to work. 5.) Packages never get to stable. PEAR's guidelines encourage developers to not prematurely make a package stable but many packages are abandoned in the alpha or beta state even when the code is 'stable'. This discourages others from using PEAR packages. I think many of these problems will be solved with PEAR2, but it won't be a magic bullet. As a member of the PEAR Group, I will make sure PEAR2 addresses the problems I see above. Greg mentioned the PEAR2 coding standards being an issue. I greatly value coding standards, but feel that it is an issue that is easily "bike-shedded". I don't think small details in the coding standard will make-or-break its success; what will be more valuable is getting people outside PEAR adopting the PEAR coding style. The work the sub-group did with outside projects was excellent in this regard. Cheers, Mike G (gauthierm)