Disclaimer
I think I need to add a disclaimer first. First of all, I have much respect for all those that have contributed to PHP. The whole core team, the QA and documentation teams, the accidental developer, the extension writers, and all those I’m forgetting in this list. They all have made a difference and have enabled me to earn the money I’m making these days. I earn my living from this awesome language that has been created and evolved over the years. So even though I might be a bit critical of people or processes, I don’t mean to insult anyone.
I do think, however, that PHP needs change. And hopefully the discussion triggered by the fork will actually accomplish this. It may take a while, or it may only take a short while, but change is needed. Now, I have not contributed anything to core. I write a couple of tests during the PHP TestFest events that PHPBenelux organized over the years, but that’s it. I have, however, seen things happen. Or sometimes not happen, while they should.
The background
Earlier this week, a link started popping up on Twitter. The link was to a fork of PHP which contains some changes/improvements, all developed by the same person. The comments to the blogpost ranged from positive to bashing and negative to simply business-like. Where I like the first ones, and can appreciate the latter (Derick commented about the fork not being allowed to be called PHP by the PHP license), the negative comments seemed useless. And this became an issue when (from as far as I saw it) Jonathan Wage brought this up on Twitter, wondering whether it wouldn’t have been better to be constructive instead of calling names and bashing. Early on in the discussion already, Rasmus chimed in stating that he already had been in touch with the developer and was trying to get him on board PHP as a contributor (which I was very happy about), but the discussion raged on and exposed an issue that has been there for quite some while already: Attitude.
Attitude
Now, first of all, all of the members of the core team I’ve met so far have been really nice people. It’s nice to talk to them, discuss PHP and related topics, and they’re usually very helpful when I have a question. But some seem to have a dark side that only comes up online, once in a while. Either on Twitter, or on the internals mailinglist, or as exposed today, in comments on blogs. This attitude problem is holding back people. I’ve talked to people outside of the core team with great ideas that did not dare send an e-mail to internals because they were afraid of being flamed. And the problem is: They are right. This happens regularly.
Internals
I think books could be written about the internals mailinglist. I myself was only subscribed for about 5 minutes. Why? Well, apparently I subscribed in the middle of one of these “discussions” about a feature proposal (I can’t even remember which one). Anyway, in the timespam of about 5 minutes after subscribing, I literally got tens of e-mails. Now that in itself is not a problem, but the general tone of the e-mails was very negative. All this hatred and negativity got to me, and I unsubscribed. Done. Since then, I’ve only in a while read through the archives, and while there are definitely enough decent discussions going on, the negativity seemed to pop up on a regular basis, so I never resubscribed.
Now I’m not a core contributor, neither am I a very likely potential contributor (since I don’t do C), however if I already have these issues with the internals-list, I can imagine how potential contributors will feel when they have this idea of a contribution that they want to propose. Sure, the proposal might be received very well and there might be no problem at all, but because of the regularity of the negative responses, I’d definitely think twice before posting the proposals. Truly, internals is not newbie friendly. And this is definitely something that should change if we’d want more contributors outside of the current core team. And I think we should want that, because the core team is busy with other stuff as well (work, life, such things).
Public statements
Another thing that should be changed is that the core team members should be more careful with what they say “in public”. Here, I mean on Twitter, Facebook, in blog comments etc. Even if those statements are not targeted directly at people, a lot of people still read them. And if they’re negative, bashing people, calling them fools or whatever, then that will stick. And at some point, it might stop people from trying to contribute to PHP. We should embrace them (even if they take a wrong approach in your opinion). Try to be constructive, try to convince them in a positive way about the way you think things should be done. This helps the overall community a lot more than bashing people and spreading negativity and hatred.
Management
Right now, the core team takes care of whatever they come by that they can handle in their precious “PHP-time”. They do an awesome job, but perhaps it would be good if one or perhaps a small group of people would try to manage this a bit more. Have an overview of open tasks, bugs, feature requests, anything that needs to be done. I sometimes get the idea that a lack of organization is sometimes preventing speedy response or handling of things. It would be very good if someone or a small group of people would have this overview, and be able to chase people when things don’t get done. Not to be angry at them, but to check if they can actually do it, and otherwise find someone else that can do it. Again, we don’t need negativity, but we could use a bit more progress.
We’ve seen this management work well in other projects, for instance Zend Framework, symfony, Agavi, you name it. You can like those frameworks or not, but the fact that there’s people that have an overview on those teams and that dare to make decisions definitely benefit the progress of the frameworks.
Community manager
Perhaps community manager isn’t even the right word for it, but I think we could use someone that can try to keep the internals (and other?) mailinglists in check a bit, trying to keep flamewars from erupting, but also reporting to the community at large what things are discussed and what decisions were made and why. Especially the why-part is important. One example, if the why was explained to “the wider community” a bit better, I’m sure we would’ve had a lot less discussion on the namespace seperator. The choice for the current seperator is not a bad one at all, but many people thought it was a best one because they didn’t know about all of the pro’s and con’s (probably also because they, like me, didn’t want to subscribe to internals).
Make contributions easier
This has already popped up on Twitter as well in the discussions, but I think contributing to PHP should be easier. Right now, the process is hard. Discuss, make a patch, discuss the patch, alter the patch, discuss it again. And all this on a mailinglist that has a lot of other discussions going on. And there are tools available that make this easier. Github for instance. Funny enough, when migrating away from CVS, the majority of the votes was for moving to Git and Github, yet for some reason we ended up on Subversion. But Github makes is a lot easier to contribute by forking, committing to your own fork, then sending a pull request. All discussions are grouped into the pull request, as are any changes that are made because of the discussions. And in the end, it’s a matter of merging those changes into the central repository. No noise to disturb the feature discussions, more to the point discussions, and easily merging stuff into PHP itself. I’m sure there’s similar tools also for other DVCSes. I don’t really care, but I think this approach is much better for the ease of contributing.
Concluding
PHP is an awesome project but due to the popularity of the language the current processes have became a problem rather than an asset to the community. Change is needed, and there are people that can do that and are probably willing to do that. I hope the discussion triggered by the fork will result in some good changes. Let’s be more constructive, and do less hating. It’s not necessary to hate this much. In the end, the PHP community is like a second family. And a good one at that.