These are some AI-generated project names, courtesy of Namelix.
I write about developer innovation and new technologies for a VC firm called Project A. Every now and then, we develop projects that we’d like to open source. Coming up with names for these projects is always a challenge and each team has a different approach. I’d like to describe how we named a couple of our projects and what we learned along the way.
One of these projects was initiated by our data engineering team and another by our back-end team. Despite having different use cases, both of these projects have a similar theme — they enable developers to efficiently process data from different sources and pipe it to different systems.
Coming up with a name is never an easy decision. Babies, bands, top-secret projects, new products, and companies — someone, somewhere has to name them. Naming an open source project isn’t quite as “high-stakes” as naming a baby but it ain’t a walk in the park either.
You can give an internal development project whatever crappy name you want, but if there’s a chance you’re going to go public with it, there are several reasons why you should put some effort into a decent name (besides simply avoiding ridicule).
“A good name can help a company or product become successful, of course, but it can also help the lowliest code library find an audience, help formalize an informal process, and propel ideas about the world toward becoming talking points throughout it.”
– Greg Leppert and Willem Van Lancker, Onym
Admittedly, we didn’t ask our marketing team for any tips about naming. They’re busy folks and we didn’t want to bother them with a highly technical project that we were going to share for free. For open source projects, you probably won’t need to worry about traditional marketing anyway — at least not when starting off.
However, earlier in my career, I had collaborated with marketing teams on product naming and got to know some of the experts that they trusted. I started reading what these experts had written about naming and branding. Some of their ideas and concerns are still highly relevant for open source software.
For example, I love this quote:
“We should lower our sights when it comes to naming. Because company names, like pretty much everything in life, fall on a bell curve. There are a few fantastic names, a whole bunch of okay-to-good names and a few truly awful names.
The problem is, the surest way to end up with an awful name is by aiming for a fantastic one.“
— Doug Kessler, Velocity Partners
It addresses how much time you can potentially waste trying to come up with the perfect name, and foreshadows some of the problems that we personally encountered. The first problem is…
Whatever you do, you should keep the group small — I would recommend no more than 5 people. Any larger and you’re going end up with costly review cycles and discussions. Also, decide the group in advance and stick to it — gradually involving more and more people can undo any previous work and bring you back to square one.
Or you could also leave the entire responsibility up to a senior member of your team. The creator of Maria DB, Max DB, and MySQL simply named those projects after his kids: “Maria”, “Max” and “My”. However, this strategy didn’t go so well for us.
The backend project was first conceived a couple of years ago, by our CTO and a few of his colleagues. They were joking around and thought it would be fun to name the future project “Wayne” (no one had any children named Wayne). Now, I don’t want to offend any people with that name, but we felt it had certain connotations that we wanted to avoid.
Not really the association we were going for — Wayne on YouTube (Image: YouTube)
In all fairness to our CTO, “Wayne” was just a working title. He quickly needed a name so that he could discuss the thing that we wanted the team to build…without calling it “the thing”. However, most of us agreed that we needed a better name.
Many development teams have flat hierarchies and try to involve everyone in big decisions. So, of course, we sought input from everyone in the team. Unfortunately, this strategy can lead to a lot of…shall we say…“noise”.
Think of what happens whenever an organization decides to let the internet suggest a name for a product or project. As the New York Times wrote in 2016: Boaty McBoatface happens. Nerds will be nerds.
And so it was, that names like “Crunchy McCrunchFace” and “BusinessObject McBusinessObjectFace” were some of the first suggestions when we tried to name our own projects (full disclosure, the second one was mine). People are also going to suggest names from popular culture such as “Gargamel”, “Tyrion”, and “Optimus Prime” — but good luck if you want people to find your “Tyrion” project in Google.
Of course, it’s fun to do some free association but it probably wouldn’t do any harm to skip this part.
Marketing teams have all sorts of complex methodologies that they like to use for this. For example, in his article on rebranding, Doug Kessler describes how they plotted words on scales such as “evocative vs descriptive”, “emotional vs rational” and “playful vs enterprisey”. They also arranged words that sent “the right signals” into a sphere of associations.
If this stuff floats your boat, then by all means, give it a try — but I’m guessing you’d rather be coding than pinning names to an ideas board. And luckily, some of these processes have been automated by AI. While we were trying to figure out how to come up with a name, our CTO discovered an interesting tool called Namelix. According to their website, Namelix “uses artificial intelligence to create a short, brandable business name”.
We weren’t after a business name but were game to give it a try. Namelix wants you to enter a few keywords about your business, so I entered the most generic words that related to our tool “backend” “database” “software”. I opted for a medium length name and chose a “name style”. There are 8 styles to choose from and I opted for “Misspellings” (like Lyft and Flickr).
Some of the suggestions were baffling:
“Scraink”, “Boonry”, or “Treesus”?
If you need to come up with a name for your emo rap trio, the “Misspellings” option might work for you. But there was no way we were going to name our project “treesus”. I tried again with the “Compound Word” option (like “FedEx” and “Instagram”). Those suggestions were even odder:
“Nannystate”, “Spyware”, or “Failapp”?
In all fairness to Namelix, I did cherry-pick the funniest examples, but nonetheless, I couldn’t find anything that I liked and I didn’t want to spend hours tinkering with the settings.
However, Namelix did help with clarifying the types of words that we should consider. To see what I mean, have a look at their “name style” options:
Incidentally, our data engineering team had structured their naming process around on similar “naming styles”. Which leads me to the next point:
Our data engineering team had people propose names in categories such as “Italian words”, “Swahili words”, “Minerals”, “Characters from Roman Mythology”, “Plant Names” and “verbs”. If you agree on the categories that you want to use first, you can avoid the task of filtering through a whole bunch of random junk.
The “verbs” category is particularly important — you want to build a list of verbs that describe what your project does. Even if none of them are suitable for a name, verbs are especially useful for triggering inspiration.
To start off, our data engineering came up with simple verb-object pairs that described their project. Here are some examples:
For each of those principal “actions”, they brainstormed further verb “associations”. For example, here are some examples of verbs that they associated with the “ETL” action.
They then translated these verbs into Swahili. Swahili seems to be a favored language when it comes to naming projects. I suspect that Swahili words appeal to English and German speakers because they have a melodic texture and are pleasing to vocalize (maybe this has something to do with the bouba/kiki effect).
Again, here are some of the ETL verbs with their Swahili translations.
The name that the data engineering team liked best was the last one: ‘mara’ — it was short, simple and easy to pronounce.
Sometimes a good backstory provides the best option
Our backend team had more of an intuitive approach. For them, it was more important that their name had a good backstory or anecdote that they could share. Our lead backend developer tried to think of metaphors for his team’s project. Then he hit upon a childhood memory — he remembered how much he loved making herbariums at school.
The Herbarium — our lead developer’s childhood passion.
He felt that the “herbarium” was a good metaphor for his team’s project. The project was an application for defining business objects independent of any database or tool. Different systems could then pull data whatever structure they require.
For our lead backend developer, each business object was kind of like a pressed plant. Each plant has its own shape and attributes, but it gets flattened into a consistent form so that all of these plant samples can be stored and compared together in one place. He shared this idea with the team and everyone liked the metaphor.
Some people felt like “herbarium” was a bit of a mouthful, so they shortened it to the more diminutive “Herbie”. But their naming quest wasn’t over yet…
Before you make a final decision on the name, make sure you find out what shows up on the search results page when you search for that word online. Branding professionals do this so that they can find out how stiff the competition is for the search results rankings.
This isn’t a huge priority for most open source projects — you’re not trying to build a brand, you just want to share your project. However, you don’t want to find out too late that your project name has some unexpected connotations or associations (For example, Ikea had to deal with this problem when they expanded into Thailand).
Incidentally, our data engineering team was not immediately aware that “mara” also refers to an odd-looking mammal.
That was until our Chief Data Officer went to the zoo with his family and spotted this sign:
Fun fact: Here in Germany, there’s a very logical system for naming animals (as illustrated by this German animal names flowchart) so in this neck of the woods, the “mara” is also called “Pampas Hare” (Pampashase).
Fortunately, the Mara is kind of cute and it made for a great logo.
Not everyone comes off so lucky, however. The point being, it’s better to be safe than sorry — even for a small open source project. What’s more important is searching on Github.
Try checking the following URL patterns to see what comes up for your chosen name:
https://github.com/<name>
https://<name>.github.io
We like to store our projects under their own organizations in Github so that they’re independent entities from the main “Project A” organization. These special projects consisted of several repos and we didn’t want them to get mixed up with all the other Project A repos.
That’s why it was important for our data engineering team to get the account https://github.com/mara and for our backend team to get https://github.com/herbie.
However, these short snappy names are often taken, but if you’re lucky, the name might belong to an inactive account. You can find out by reviewing the account activity. If there’s little to no activity, you might be able to claim the name according to Github’s username policy. This was indeed the case for both the “mara” and “herbie” accounts. After contacting GitHub support, both names were made available for our projects.
Unfortunately for the backend team, they hadn’t paid enough attention to the general search results in Github. After everyone agreed on the name and set up the repos, people started discovering other “herbies” such as a German flat-file CMS project and another small project from the University of Washington. Maybe “treesus” wasn’t such a bad idea after all?
While a double up is not ideal, it’s also not as critical as having a duplicate brand name. As long as the projects are in separate niches of the open source ecosystem, you can probably get away with it for a while. However, if another project with the same name becomes astronomically popular, your project risks drowning in a sea of content about its more well-known namesake.
This is not really a “must-have” but if you think that your project might gain traction, you could also check top-level domains that are popular with open source projects, such as “.org” or “.io”. Just be aware that some domains can come with a hefty price tag. At the time of writing, the domain “mara.io” was being sold for $1,999 — which definitely wasn’t an option for our data engineering team.
As a final precaution, try to use the name in at least 5 sentences and make sure that there are no contexts where it sounds weird.
For example, have a look at these sentences containing the term “Splunk” — the name of a popular application for analyzing machine-generated big data.
“…to splunk your new data, run the demo script…”
“…you have the data but how will it be splunked?…”
“…see our tutorial on splunking Perforce Data…”
“…check to see if Splunk knows about your script”
“…both apps are enabled on this Splunk instance..”
Splunk is definitely a memorable name and a strong brand, but for British English speakers, there’s something disconcerting about using the word “Splunk” as a verb — it sounds somehow vulgar. A list of usage examples can help uncover such linguistic idiosyncrasies and it can also give you ideas on rules for correct usage.
Of course, I couldn’t finish a blog post about names without mentioning the indispensable naming resource “Onym”. It’s a fantastic website which links to curated content about every aspect of the naming process, including many more tools that can help you with brainstorming.
I wish we had found out about this resource a lot earlier — we could have saved ourselves a lot of time!. But hopefully, these tips help you avoid some of the naming pitfalls that we encountered. Also, if you have any interesting stories about how you came up with a project name, let us know!
Merlin blogs about developer innovation and new technologies at Project A — a venture capital investor focusing on early-stage startups. Project A provides operational support to its portfolio companies, including developer expertise. As part of the IT team, he covers the highlights of Project A’s work helping startups to evolve into thriving success stories.