When WordPress was first created, PHP was the obvious language to write it in. The language was pervasive, was all but ubiquitous on hosting servers and was considered a current language. That has changed. PHP is as ubiquitous as ever, but now showing its age. The next generation of developers aren’t flocking to PHP and most modern web apps are written in something else. So what is an open source project like WordPress to do? With a PHP codebase, you are effectively creating an interest barrier for many younger developers to contribute to your open source project. WordPress may be the biggest current example, but this conundrum is going to be a continual problem for other large open source projects. How do you keep an open source project modern and relevant when it’s built on top of an aging language?
Historically speaking, software has generally had a clear delineation between creator and consumer. The consumers vastly outnumbered the creators. Today a much larger percentage of the population is tinkering with code. The line between creator and consumer continues to blur. With today’s open source projects, specifically those where you’re working on top of it, there’s a whole new layer of contribution in the form of third-party developers. That community means everything to its relevance. The functionality of the actual product in open source software is as important as ever, but the experience of using/modifying the code behind it is now vital. Making it desirable to work with is as important as making it work.
Ruby on Rails is a good example of making an open source project desirable. The development team created a compelling framework with new, interesting approaches. It created a new, and in many ways better, approach to making web apps. Almost overnight you had a huge influx of developers writing Ruby just so they could use Rails.
So what do you do when the language behind a large open source project begins to age? If you stay the course there will be a slow bleed of talent as future generations of developers migrate to modern languages and frameworks. If you immediately shift to a new language, you will lose a huge segment of its most loyal and fervent supporters-in a sense, the elders.
Here’s how I would approach it. I would create offshoots of the project in different languages. I like to think of this approach as creating tributaries of the main “river”. These efforts would be run by small teams, focus primarily on core functionality and rely heavily on the contributions of outside communities to push the project forward. Each tributary may turn into its own river or dry up altogether. The learnings from each tributary would benefit everyone. As languages begin to die, they can be let go naturally. As others begin to grow, there can be more resources devoted to it. This approach allows a project’s community not feel like it’s “stuck” with a particular language or technology.
I particularly like this system because it gives an inroad for new groups of talented people to contribute. This opens up the door for more diversity of thinking and approaches to solving problems. In turn, it would likely lead to fragmentation. It would also piss a lot of people off in the core community. However, I believe the alternative of doing nothing eventually would be worse.
Languages can be very old and have vibrant communities around them… Until they don’t. This can happen very quickly and unexpectedly. Influential open source projects need to take a proactive role in keeping their product desirable for consumers and those who use it to create. Part of making it desirable is to keep it aligned and in pace with the zeitgeist of the next generation’s talent. Otherwise they’ll move on, and everyone else with them.