Open Source Projects Must be Bigger than the Languages They're Written In

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.

6 thoughts on “Open Source Projects Must be Bigger than the Languages They're Written In”

  1. This would be a great idea, PJ. In the same way that a CMS separates the content from the code, this separates the code from the … programming language. It’d makes WP more language agnostic, like we should all be doing with our websites, making them device agnostic.

    Obviously, like you said, it’d be a headache to manage it all, but in the end I think would be worth the troubles and would cross-pollinate each branch with ideas from others.

  2. Quite thought provoking. And also, quite hard to imagine. Take your WordPress example: envisage for us what the “offshoots” model looks like. How would it work in practice? Just one example would do — I’m having trouble coming up with something viable!

    (Btw – I imagine the “offshoots” metaphor works better than “tributaries”. Tributaries feed in from a variety of sources, rather than grow out from a common source. Yes, I must be a pedant. 🙂 )

    1. Thanks for the feedback David, that’s a damned good point. I’m trying to think of words other than “branch” that describes this phenomenon… Any thoughts?

  3. This post is just trolling, doesn’t make any sense. You have not idea about what is PHP today, you are just following the gossip to be a good cool kid. I would rather say refactor the core with modern PHP rather than changing the language. Indeed you didn’t say that PHP is not good as language, because you can’t say that, you just said it’s not cool… and this is sad…

    Did you think by any chance that part of the success of WordPress is because it’s written in PHP?
    Do you have any idea about what means rewrite it in another language? Moving the base, rewriting its plugin, reach the same code maturity and stability.
    What do you think they should do when a new technology/language become more cool than the current? what about node.js?
    Do you think they should keep a team for each language they should implement rather than having just one specialized team?
    Do you think that focusing in learning new languages is more productive than focusing on writing a good core?
    Last… do you have an idea of what are you talking about?

    What prevent you or any other developer to write a WordPress-like platform in Ruby or whatever, because rewriting WordPress in another language is like writing a new platform from scratch. Actually there are several similar platform in several languages, maybe they are not good as WordPress exactly because they are not written in PHP, less developers, less people ready to learn it, less people ready to write plugin, less hosting available and so on.

  4. @Neo, this isn’t an issue today, tomorrow or next week. This is an issue years out from now. And yes, I know how much time it takes to rewrite a core, that’s why you start before it’s absolutely necessary.

    We’ll see if I’m right or wrong – we’re not going to know for a while. What I will say is that the I don’t hear or read many young codes expressing how much they love writing PHP.

Leave a Reply

Your email address will not be published. Required fields are marked *