In the older days of open source software, major projects tended to have their Benevolent Dictators For Life who made all the final decisions, and some mature projects still operate that way. Guido van Rossum famously called his language “Python” because he liked the British comics of the same name. That’s the sort of thing that only a single developer can get away with.
However, in these modern times of GitHub, GitLab, and other collaboration platforms, community-driven decision making has become a more and more common phenomenon, shifting software development towards democracy. People begin to think of themselves as “Python programmers” or “GIMP users” and the name of the project fuses irrevocably with their identity.
What happens when software projects fork, develop apart, or otherwise change significantly? Obviously, to prevent confusion, they get a new name, and all of those “Perl Monks” need to become “Raku Monks”. Needless to say, what should be a trivial detail — what we’ve all decided to call this pile of ones and zeros or language constructs — can become a big deal. Don’t believe us? Here are the stories of renaming Python, Perl, and the GIMP.
A Renegade Python
Next year marks the end of life for Python 2 — and this time we mean it! Although usage statistics have shown a steady decline of Python 2 in favor of Python 3 over the last years, there is still a significant amount of Python 2 code out there. Expecting that every single one of those projects will migrate to Python 3 by New Years is unlikely. For one reason or another, it can be almost guaranteed that Python 2 will stick around for another while, officially supported or not. But its days are probably numbered.
Still, just suppose that a bunch of people teamed up around the idea of developing Python 2 further, for whatever reasons. After all, humans are complex, and someone out there was bound to lead a crusade against parentheses in
This situation is not hypothetical, and when [Naftali Harris] proposed calling his modernized Python 2 branch “Python 2.8”, the Python Software Foundation had a thing or two to say about it. The name has since been changed to Tauthon, but the remnants of the name clash are still to be found in the URL where it was announced. The Pythonistas, ever a witty bunch, decided that they’d better name-squat on “Python 2.8” to prevent any future misunderstandings. To quote: “The current un-schedule is: 2.8 final — Never”.
That’s the way forks are supposed to work after all. A project spins off of another and eventually develops enough of its own identity that it needs a new name to label the new contents. Whether Tauthon will gain any traction is beside the point. With a brand-new name, nobody is going to confuse it for mainline Python.
A Tale Of Two Perls
Similar to Python, Perl has had two major versions existing in parallel for a while now: Perl 5, which followed a natural version increase from its predecessor versions, and Perl 6, which always followed the goal to get rid of some old baggage, and has since grown into more of a sister language than a successor for Perl 5. A common statement is that “Perl 6 is not Perl”, and it’s largely true, except in name. Unlike Python, though, there is no community consensus that Perl 5 needs to be retired.
Will the new “Perl” need a new name? What happens when you type
perl in the command line?
The old-school Perl community is not eager for Perl 6 to be seen as something “one better” than their beloved Perl 5. At the same time, the Perl 6 community wishes to get rid of the Perl 5 stench in their shiny new language. The situation with the two Perls is even more clear-cut than with the Pythons, except that Perl 6 has a larger following than Tauthon ever did.
The Perl 6 community has recently opened the discussion to find a new name for good, but somehow changing a name is harder than adding entirely new syntax to the language. If you need proof, try following the still ongoing discussion spanning several hundreds of comments — going in circles and full of everyone’s unique opinions — despite a consensus for Raku as new name. Clearly, there’s more to a name than meets the eye.
GIMP: Take It Or Fork It
Which brings us to the GNU Image Manipulation Program (the GIMP). People find this nickname offensive frequently enough that even its FAQ deals with it. Is it time for a name change? The official word on this is: the name will stay, but feel free to fork the project with your own name.
Well, a recent, unsuccessful attempt to request a name change challenging that very FAQ led in the end to just that: the Glimpse fork. Aiming not only for a new name, but having ambitious plans that include rewriting the GUI from scratch and adding their own set of features in the future. Time will tell how a community-driven development of this GIMP fork will prevail — for the time being, the main effort appears to unironically focus on, well, whether they should choose a different name. Oh no!
Who’s To Name Our Software Then?
We all know naming is hard, but in the grand scheme of any project, the name is really just one small detail. Yet somehow it’s emotionally laden. Here we have three examples: one of a single-author renaming that went fairly easily, one that should be smooth but is nonetheless heart-rending, and a third that’s a change in name only, for name’s sake. The renamings seem to be proceeding at speeds that are inversely proportional to the number of developers. One possible response to all of this is to throw up your hands and despair at the inefficiency of making decisions by committee, or even worse, by mob rule.
But maybe it’s also a heartening reminder than open-source software is made by many, many people who’ve put heart and soul into what they’ve created, to the extent that they identify with the work strongly enough to give it a name, like a dog or a sports team. Maybe it’s the purest sign of open-source love.
Or maybe it’s a tempest in a teapot. After all, what’s in a name?