Get involved in PEAR!

I often read on the mailing-list or in some forums that PEAR is nothing more than a repository of mixed-quality PHP packages, and is ruled by a bunch of temperamental people. As such, people reading such comments think that a) the whole PEAR project is not even worth a look, or b) getting involved in PEAR is impossible if the core PEAR guys are not in the mood of approving the package you just submitted.
While I *have* seen some heated debates between some core developers and "outsiders" in the past, that resulted in having the new package rejected and the newcomer pissed-off, that is certainly not as frequent as you may think (ever heard the adagio «A falling tree makes more noise than a growing forest»?), and in the few cases that happened it was because of a wrong attitude.
To avoid it, you just need to be polite, open to suggestions, and accept the rules of the community you're trying to enter. If your package is original, generally good and fits PEAR, then by all means, submit it and wait for suggestions and votes! I'm sure you'll find a lot of nice people in PEAR to work with!

Do you think you can do better?

We're all happy to hear new ideas, or to improve something we already have. There are many ways to contribute, and while proposing a new package could be the most "rewarding" for the creator's ego in the short term, it's certainly not the only one.
Quoting the PEAR manual: "PEAR is an open source project, which means that everyone can help improving it. Improving doesn't always mean writing code. It can also mean reporting bugs, giving feedback, submitting feature requests and even financial support".
By the way: I didn't see "grunting and bitching" in this list ;-)

Bugs and patches

One of the most useful contributions you can make is reporting bugs when you find one, or help in fixing them.
If you want to have a bug fixed, maybe you could send the package developer some incentives to make it happen faster ;-)
If you have some spare time and really want to get involved, open this page and see if you can help fixing existing bugs. You don't need a CVS account to post a patch. Eventually, if you show your dedication, you can be "promoted" to active developer, if you want so and if the package lead values your help.
If the original developer isn't active anymore, you can take over the unmaintained package.


If you think that the documentation for a PEAR package is incomplete, informing the developer about the undocumented area(s) may be a sensitive action. Better yet, if you are confident with the package, and can provide some examples, tutorials, guides or give a hand in writing the docs, contact the pear-doc mailing-list, or read here about the peardoc DocBook format.


Often, when we introduce a new feature in an existing package or are working towards a nice API, we may ask for feedback, to collect some ideas, suggestions, or hear some use-cases. Unfortunately, we don't always receive many comments. If you have experience on the topic, then speak up!

OK, where should I start?

If you paid attention, I already pointed a lot of ways to "get started". If you lack ideas and/or still need some concrete suggestions, read on.


The Mail_Queue package probably went "stable" too soon, but it still needs a lot of love. Since we can't change the API of a stable package, here's a list of improvement needed for the new Mail_Queue2 (for whoever feels brave enough to write it):

  • support for multiple recipients (Cc/Bcc) (this is somewhat solved in CVS already)
  • db (row-level?) locking to avoid concurrent access and multiple deliveries
  • proper logs and error handling (mostly non-blocking, since we're sending emails in batches)
  • support for priority levels
  • accept an already instantiated db container
  • support for persistent SMTP connections
  • better queue/buffer management
  • new containers (PDO)
  • ...


Another popular package that needs some help is MDB_QueryTool. The most urgent thing to do is implement identifier quoting (i.e. quote table names). There is more than one request about it already.
Then it would probably benefit from a full source code review, it's been ages since the last spring-cleaning session ;-)
It would also be cool if someone could backport to DB_QueryTool the last changes applied to MDB_QueryTool.

MDB2 and charsets

I've already asked for feedback in a previous article, and received zero comments, but the issue is still open, and its solution is critical for other packages as well, Translation2 in primis.


Translation2 is supposed to make the developers' life easier when building a multilingual application/website. It has been through a looong beta-cycle, and still hasn't reached the "stable" status, since I'd like to receive some more feedback about it.
I'm particularly interested in suggestions on how to handle charsets and encoding with the db drivers, how to deal with "default" translations (i.e. default replacement for untranslated strings), about its cache decorator, about new containers (php array, ini files, ...), etc.


An idea for a new package (or group of packages): a converter to move data among the existing Translation2 storage containers, e.g. database to XML, gettext to database, array to database, etc. I'd love to see a core module (maybe with an intermediate storage format), and a series of drivers (one for each Translation2 container) to convert to and from the format used in the core module.

Are you still reading?

What are you waiting for? Roll up your sleeves and get your hands dirty! Get involved now!

Lorenzo Alberton

Lorenzo Alberton Lorenzo has been working with large enterprise UK companies for the past 10+ years and is currently CTO at DataSift. He's an international conference speaker and a long-time contributor to many open source projects. Lorenzo Alberton's profile on GitHub Lorenzo Alberton's profile on LinkedIN View Lorenzo Alberton's profile on PHP PEAR
View Lorenzo Alberton's Twitter stream Lorenzo Alberton - Sun Certified MySQL 5 Developer PHP5 ZCE - Zend Certified Engineer


AJAX, Apache, Book Review, Charset, Cheat Sheet, Data structures, Database, Firebird SQL, Hadoop, Imagick, INFORMATION_SCHEMA, JavaScript, Kafka, Linux, Message Queues, mod_rewrite, Monitoring, MySQL, NoSQL, Oracle, PDO, PEAR, Performance, PHP, PostgreSQL, Profiling, Scalability, Security, SPL, SQL Server, SQLite, Testing, Tutorial, TYPO3, Windows, Zend Framework

Buy me a book - Is It Just Me Or Is Everything Shit