Bonus- Rasmus Lerdorf - Inventing the PHP Language

Right, so it started in 1993, when I saw the Mosaic web browser. That was when I got really interested in the web. I’d been doing Gopher and IRC and other Internet-related things before then. But with Mosaic, I could suddenly explain what I was doing to my mother. So I knew this thing was going to be very, very interesting. I was living in Mountain View, California but I moved back to Toronto to do consulting. And I ended up consulting for a number of companies. And I wrote the same code over and over. Basically CGI scripts written in C. And I wrote similar code to handle forms, and post data, and filtering. And all, all this other common web things you end up having to write in C, if you’re writing raw C CGI programs. So, that was getting tedious. I’m not very interested in programming. It’s kind of tedious and boring, so if I could reduce the amount of time I had to spend programming, and maximize the, the output and get to the solution quicker, that was my goal with PHP. I put together all my common stuff into a C library, hacked it into the NCSA web server, and then added a little templating system on top of that to let me easily call into it. And that was the first version of PHP. It was a productivity tool for myself. So I could very quickly go to a new client, and whip up a new web application for them, and tie them to their database, whatever they needed. And every client had slightly different requirements. So I kept extending my tool. Then other people started asking me about this stuff. They asked me how I built these things. I said, well, I’m using this little tool I built and they asked if they could have it. I said, sure why not. I mean, that’s not what I’m selling. I’m selling my services of solving problems. The tool itself is irrelevant really. It’s just my hammer. And anybody can use my hammer, I don’t care. And then they started sending me patches, which I thought was really, really cool. And they found bugs in my stuff that I hadn’t found yet. And which meant I could also go into a client’s and say hey, here we go, here’s a new version that fixes this, this, and this. And they thought I was being extremely productive. Writing all this code and fixing all these things so fast. So that’s when open source really hit me. That was in 1994, 95, before the term open source existed. But it really caught with me that I got together with a group of my peers, other people interested in the web and solving the web problem from all around the world. We all had similar problems. We faced similar issues. And collaboratively, we could build a tool that solved this problem. And that was really how PHP got off the ground. I learned a bit along the way. That in order for this to grow, I had to give up control of PHP. I had to let other people have some control. I couldn’t re-write everybody’s patches. Both because I’m pretty lazy, and it’s a lot of work. But also to give people some ownership in the project. And once they have some ownership, once they have full control over their part of it, then they become much more invested in it. And they become passionate, and it becomes theirs, not just them contributing to my project. It becomes our project and that really changed the nature of PHP. That happened around 1997 or so where I really delegated it out and gave people full access to the CVS repository that I was using to develop this stuff and, and it grew like crazy after that, both because the web grew, and PHP was sort of the right time and the right place, but also because it was very, very easy to, to get in, and get started contributing to PHP. And using PHP as well obviously has a very low barrier of entry. So both on the using PHP side and also on the contributing to PHP side I tried to keep the barrier of entry really low. It does not take much, even today, to get a CVS account in the PHP project. Source version control is a wonderful thing. It doesn’t really matter how bad the initial patch is from some contributor, we can always fix it. I’d much rather welcome new contributors and guide them along, and get them to be productive and, and useful than yell at them for having a bad initial patch. You know, from the outside you look like a well-oiled machine. You know, it’s a well-oiled machine that, that, that accomplishes things, you know, more effectively than a commercial organization. But, at the same time it’s sort of a it’s a loose, it’s a band of brothers to some degree. We have those close to 1,400 people with CVS accounts, which means they’re, those people can all commit to some part of the repository, either PHP, PEAR, PECL, the documentation tree, anywhere in there. Now they’re not all active, obviously. We probably have maybe slightly over half the people have committed something in the last year and a half. There’s no management of these people really. They sort of self-organize into smaller groups. It’s impossible to manage 1,400 people, obviously. Especially when they’re volunteers and they’re not actually going to show up to a meeting or to even read their email or whatever. But they self-organize around what they’re interested in. So we have documentation teams for the various languages. There’s a big French documentation team that just worry about the French translation of the documentation. There’s a Japanese translation team, big group of core documenters, and those guys organize themselves. There’s no big chief of this whole thing. I don’t tell people what to do. I can’t. They’re not going to listen to me. Why would they listen to me? Right? They do what they’re interested in. That’s the only way volunteers work. Then there’s the PECL guys that build PECL extensions. Generally, that’s sort of where we test out new extensions, and bring in certain ones. Like in PHP 5.1 we brought in the JSON extension. Which started its life in PECL. Next, maybe OAuth or some of the others that are big right now. So, that’s sort of how new features and new things eventually creep in. They, they live outside of the core tree, and they get enough penetration there, enough people install them, we see linux distros pulling them in, in their core version of PHP they pull in some of these things. We sort of look at what’s happening out there, and that happens. But there’s no real management of that either. And it’s a meritocracy, I mean code speaks. If you write a patch or you write a piece of code to implement a feature, that says a lot. If someone wants to disagree with that way of doing things, if they can offer an alternate implementation, that’s a really good argument. If all they do is whine about it, that’s a really bad argument, and chances are that the implementation will win, even though it may not be the best way of doing things. There is code, it sort of works, that’s what we go with. And that’s, that’s always been the default. It doesn’t always lead to consistency, but it does lead to getting the features, and actually being able to do something. Being able to connect to this type of database even though it may not be the best way of doing it. At least it gets you there. And that’s always been what PHP is about, is solving the problem. We’d rather have an ugly feature than not having the feature at all.