This is the story of the PHPCommunity.org project's beginnings. Many lessons have been learned (some the hard way), and the project has already been a success without a single line of code being written. How did it happen? To truly understand the answer, I think it is important to describe the motivation behind the project.
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, MySQL, and other technologies.
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.
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
use Perl; 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 site where Perl experts answer questions from visitors and archive the 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.
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.
The PHPCommunity.org project's beginnings trace back to March 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
use Perl;. I registered the domain to prevent it from succumbing to the same fate as domains like
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. In December of 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 email 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).
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 responsible for managing the project. Initial communication was via email.
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.
In mid-December, the project was announced on
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 email than I could ever hope to respond to. As a result, I had to resort to automation. I wrote a PHP script (of course) to parse the emails I had received and create the
firstname.lastname@example.org mailing list, and I sent out the first welcome email to all of the volunteers. I apologized for the delay in getting things started, as it had 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.
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 almost 500 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 list, this time asking for project lead volunteers. Unfortunately, the only way people could respond was by emailing me personally. 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. Email was just too slow, and it wasn't able to scale well enough for this project.
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 email 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 emailed 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, a few hundred people 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.
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.