One of my favorite things about open source software is the community. People are always eager to help, and this is evident on any mailing list. Each major open source technology has its own community, and many of these communities overlap. PHP's community is made up of the people around the world who develop with PHP whether for fun or profit (or both), and many of these people also use Linux, Apache, and MySQL.
Some technologies are older than others and thus have more mature communities. While PHP seems very old to many of us (it's been around for a decade, after all), it is still a rather young language relative to the rest of the industry. Its community, however, is one of the largest in the world.
Fame
Despite the size of the PHP community, its members are largely unknown and isolated. Outside of the core PHP developers, very few people from the PHP community are well known, and they don't know many of the other members of the community, either. Contrast this with the Perl community where there are many famous Perl hackers - people who are known just for the things they do with Perl.
Is fame important for a community? Maybe not in the traditional sense, but in the sense that it is a reflection of the social atmosphere, it is. For a community to be strong, members of the community need to know one another. They need to interact with one another in ways other than questions and answers on mailing lists. Unfortunately, there aren't any resources that support this type of environment within the PHP community.
Learning from Perl
Perl has a rich, mature community. I have been a member of
http://use.perl.org/ for a while, and from that membership alone, I have met many people in the Perl community. At conferences such as OSCON and ApacheCon (where there are both PHP and Perl tracks), I find that I know as many people from the Perl community as the PHP community.
In addition to this observation, I have also realized that the only people from the PHP community that I know are the other speakers. The gap between PHP speaker and attendee actually poses a significant challenge, because this makes it more difficult for speakers to connect with the audience or to encourage audience participation. A good speaker is one that seems like an experienced peer sharing valuable lessons learned. With the gap that exists in the PHP community, this is more difficult to achieve.
Perl also has resources such as Perl Monks, a Web site where Perl experts answer questions from visitors and archive these questions and answers so that future visitors can learn from them. In fact, with the rich variety of resources where Perl developers can seek help, Perl mailing lists are less crowded and more focused than PHP lists.
TMTOWTDI
A favorite saying among Perl developers is: "There's more than one way to do it." This refers to code, but it applies to building communities as well. While it is wise to learn from the Perl community, copying their ideas and resources is not necessarily best for the PHP community. Just as a developer might hack an open source project to better fit specific needs, so shall we hack the approaches taken by the Perl community to build our own.
PHPCommunity.org
The PHPCommunity.org project's beginnings trace back to at least 26 Mar 2003, which is when I registered the domain. My initial plans were to hand the domain over to someone who wanted to create a PHP community site that provides resources similar to
http://use.perl.org/. I registered the domain to prevent it from succumbing to the same fate as domains like
php.org.
Several months later, I decided that doing nothing wasn't the way to help make this resource become a reality. I spoke with some people at O'Reilly who agreed to offer hosting and bandwidth resources for such an effort. Then, On 01 Dec 2003, I announced the project in my blog and also mentioned it on the PHP-General mailing list. Initially, I was only asking for volunteers, because I was hoping that the project would be mostly defined by the community. Of course, I mentioned several features, just to give people an idea of my vision, but I wanted to be careful not to restrict anyone's creativity.
The response was amazing. Blogs were quickly filled with the news and were amazingly positive about the project. It even sparked interest from other communities. I was receiving more e-mail each day than I could hope to respond to, although I naively thought I could send everyone a personal reply (something that I quickly learned was impossible).
Steering Committee
I knew from the beginning that I couldn't possibly manage the project alone, and I mentioned a need for people to contribute to the global vision in my announcement. The people who expressed an interest in this task were the first people involved. In order to reference this group by name, we decided to call it the PHP Community Steering Committee, or Steering for short. This group of people were to be responsible for managing the project. Initial communication was via e-mail.
Once there were 13 people in this group, we decided to make membership by invitation only and to offer no invitations until development was underway.
PHP.net
On 18 Dec 2003, the project was announced on
http://www.php.net/. Unfortunately, this was while I was away on holiday for a few weeks. This generated an even larger response than before, and I returned to find more e-mail than I could possibly hope to respond to. As a result, I had to resort to automation. I wrote a PHP script (of course) to parse the e-mails I had received and return all of the e-mail addresses in the
From field of each message. I then created the
developers@ mailing list and sent out the first welcome e-mail to all of the volunteers. I apologized for the delay in getting things started, as it how now been over a month since the project was announced. Little did I know that we still weren't quite organized and ready enough to begin making progress.
Projects
Among other decisions being made (such as using PHP 5), Steering agreed to a list of features for launch. Projects were created from this list, and we needed project leads to manage them. With over 400 volunteers by this point, this seemed like the best way to put more power in the hands of the community.
I made another announcement to the
developers@ mailing list, this time asking for project lead volunteers. Unfortunately, the only way people could respond was by e-mailing me. Once again, I found myself being a bottleneck, and this was slowing progress. Even worse, I had no tools with which to organize the volunteers and collaborate with other members of Steering. E-mail was just too slow, and it wasn't able to scale well enough for this project.
Wiki
Because we had decided to use PHP 5, and also because we had heard positive things about coWiki, we began to use it to help organize the project planning. This gave me a much better tool to use for project lead selections as well as for communicating with the community more interactively and on a larger scale.
I created a wiki page for volunteers and sent another e-mail to the
developers@ list inviting everyone to add their name to the list of volunteers and to mention what projects they were interested in (even if they had already e-mailed me privately). I also asked them to create a wiki page about themselves.
This turned out to be a turning point in momentum for the project. Within a few hours, there were over 100 people who had created personal wiki pages. Reading through these, I realized that the development of this project was itself a community-building effort. A real community had been born.
What's Next?
During the first few weeks, I found myself being disappointed in the rate of progress. I have since realized that this project has loftier goals than simply creating a Web site. It's uniting a community in the process.
As I write this, project leads have been selected, and project mailing lists are alive with discussion. An IRC channel called
#phpc is a popular meeting place on
freenode.net. CVS accounts are being created. The first signs of real progress are evident.
The desired outcome of the mailing list discussion is a set of requirements for each of the projects. Rather than being formal requirements documents, these only need to be created so that volunteers know what they can do to help, and also so that each project can remain focused and organized. Too much organization can be a hindrance, but a project this large requires some structure.
What defines a successful project? It depends completely upon the goals of the project. This project seeks to unite a community, and it has already made great strides toward that goal. The most important lesson that I have learned is that the journey truly is half the fun, if not more.
Links and Literature 
