April 18, 2014
Number two in an occasional series of “time I wish I could have back” topics related to releasing proprietary software projects as free software.
What’s in a name?
It was famously said that there are 2 hard problems in computer programming: Cache invalidation, naming things, and off by one errors.
Naming a project is a pain. Everyone has their favourite, everyone’s an expert, and there are a dozen different creative processes that people will suggest. Also, project names are subject to approval by legal and brand departments often, which are 2 departments most engineers don’t want anything to do with. So how do you come up with an acceptable name without spending weeks talking about it? Here are some guidelines.
Avoid anything related to the company name or products
You don’t want to have corporate trademark guidelines, certification programmes, etc impacting the way your community can use the project name, and avoiding names related to company assets will make it easier to transfer trademark ownership to an independent non-profit, should you decide to do that in the future. In terms of maintaining a clear separation in people’s minds between the community project and your company’s products, it’s also a good idea to avoid “line extension” by reusing a product name
Outside of that, the number one thing to remember is:
Projects names are not the most important thing about your project
What’s important is what problems you solve, and how well you solve them. The name will grow on people if they’re using the project regularly. You can even end up with interesting discussions like “is it pronounced Lee-nooks or Lie-nucks?” which can galvanise a nascent community. Also, remember that:
Project names can be changed
How many projects fall foul of existing trademarks, end up rebranding soon after launch, or are forced to change names because of a change of corporate sponsor or a fork? Firefox, Jitsi, WildFly, Jenkins, LibreOffice, Joomla, Inkscape all started life under different names, and a rename has not prevented them from going on to be very successful projects. The important thing, in an open source project, is to start small so that you don’t have a huge amount invested in the old name, if circumstances require you to change it.
Avoid a few pitfalls
Avoid using anything which is related to the trademarks of competing companies or projects, unless it is pretty abstract (Avid to Diva, Mozilla to Mosaic Killer, Eclipse to Sun).
That said, don’t worry too much about trademarks. Yes, do a quick search for related projects when you have a shortlist, and check out USPTO. But just because there is a Gnome Chestnut Farms in Bend, Oregon doesn’t mean you can’t call your free software desktop environment GNOME. Domain of use is a powerful constraint, take advantage of it.
Avoid potentially politically incorrect or “bad language” words. Also, avoid artificially smart acronyms. The Flexible Add-on Release Tracker might seem like a good idea, but… don’t. GIMP is a notable exception here to both rules, and countless days have been spent defending the choice of name over the years.
Do worry about the domain name. This will be the primary promotion mechanism. People shouldn’t spend time trying to figure out if your project is hosted at “sandbla.st” or “sandblast.org” or “ProjectSandblast.org”. Make sure you get a good domain name.
Empower a small group to choose
The decision on a name should belong to 1, 2 or 3 people. No more. Once you realise that names are not the most important thing, and that the name can be changed if you mess up badly, that frees you from getting buy-in from everyone on the development team. The “committee” should include the project leaders (the person or people who will be identified as the maintainers afterwards), and one person who is good at facilitating naming discussions (perhaps someone from your Brand department to ensure their buy-in for the result). Beyond that, do not consider surveys, general calls for names, or any other process which gives a sense of ownership of the process to more than 2 or 3 people. This way lies many weeks and months of bikeshedding arguments.
Have a process
- Start with a concept and work from there. Break out the Thesaurus, make a list of related concepts.
- Names can be abstract or prosaic, it doesn’t really matter. Discourse is one of the most wonderfully prosaic project names I’ve seen, but StackOverflow has nothing to do with a questions & answers forum. Ansible is a made up word, Puppet and Chef both evoke wonderfully orchestration while being dictionary words.
- Keep the shortlist to names which are short and pronounceable in multiple languages.
- Cull ruthlessly – don’t keep “maybe” names. If you get to the end, go back to the concepts list and start again.
- If you get to a shortlist of 2 or 3 and can’t decide, use random() to pick the winner or go with the choice of the project leader.
In general, don’t spend too much time on it. You should be able to get a couple of candidate names in a few days of discussion, submit them to Legal for a trademark review, and spend your time on what really matters, understanding your users’ problems and solving them as well as you can.
Of course, this is easier said than done – good luck!
April 17, 2014
One in a series of indeterminate length I am calling “mostly unimportant questions which take an inordinate amount of time to resolve when releasing a project as free software”. For the next topic, I’m hesitating between “naming”, “logo/icon/mascot design” and “mailing lists or forums”.
Choosing a license
Free software projects need licenses. But choosing a license is such a pain that most github projects don’t even bother (resulting in an initiative by Github to rectify this). And when taking a closed source project and making it free software, the topic of license choice will take a huge amount of time and effort.
I have found the following questions accelerate things nicely.
- Does the project exist as part of a greater ecosystem (eg. Apache, Eclipse, GNOME, Perl, Ruby)?
- If so, is there a predominant license in that ecosystem (eg EPL for Eclipse, MPL for Mozilla, MIT for Ruby gems)? Then use that license.
- Does your business model depend on you having total control of the project for the foreseeable future? (Aside: If so, consider changing your business model) Consider GPL v3+/proprietary dual license
- Do you want to grow a vibrant developer community around your project? If not, why not? Avoid dual license, copyright assignment
- Do you want to grow a vibrant service partner/extensions ecosystem, including proprietary extensions, around your project? Avoid GPL v2+ or v3+ – prefer MPL v2 or Apache v2
- Do you have any dependencies whose licenses you must comply with (eg. GPL v2 hard dependency)? Ensure you can distribute result under a compliant license
- Do you have concerns about the patent portfolios of potential project contributors? Choose from GPL v3, MPL v2, Apache v2 for stronger patent protection for contributors
- Do you believe that all contributors to the project, including extensions, should be subject to the same rules? Choose GPL v3
- Do you believe that the source code is free, and people should do whatever they want with it as long as they give you credit? Choose MIT or Apache v2
- After answering these questions, are you considering a license outside of (L)GPL v3, MPL v2, Apache v2 or MIT? Don’t.
After all of this, there are still situations which can lead to different outcomes – perhaps you want to join a specific non-profit later, and your license choice will be influenced by that. Perhaps you have a dependency currently which you plan to work around later, and you might dual license source code contributions under multiple free software licenses to allow relicensing easily (as OpenOffice.org and Mozilla have done). But the answers to the 10 questions above will at least reduce the scope of your search to one or two licenses.
Any considerations I have missed? Comments welcome!
April 17, 2014
I realised recently that most of my writing has been of the 140 character format recently…. I plan to rectify this, starting today.
February 11, 2014
There are times in a long career when you have to turn your back on what’s gone before. In work, this is easy. People stop giving you a paycheck, you stop turning up to work. And yet, some of my best friends are people I worked with 10 years ago.
In open source, it’s harder. You build relationships, you grow emotional attachments to projects you work on.
When life moves you on from a project, you stay subscribed to mailing lists, you add mail filters to move them to a folder you read less and less frequently.
When you hit a threshold where you no longer consider yourself a developer or contributor, you keep watching from afar, and when the project takes a direction you disagree with, that you know you would have argued against, you feel a little sadness.
After a while, this build-up of guilt weighs you down. But letting go is hard to do.
I’m learning. Trying to get better at letting go. The next generation needs to find their own way. It’s liberating and saddening in equal measure. Old friends: we will stay friends, but I need to trust you to make your own way.
June 8, 2013
freesoftware, General, openstack, red hat, work
Over at community.redhat.com, the Red Hat community blog, I have posted an article detailing some of the value I see to customers of companies who support and build on free software. The article is basically notes from a presentation I will be giving next Wednesday at the Red Hat Summit, “Community Catalysts: The Value of Open Source Community Development”. The problem statement?
It’s not always obvious, however, what the value of that is to our customers. The four freedoms of the free software definition which personify open source software – the freedom to use, study, modify and share modified copies of the software – at first glance appear to benefit only participants in open source communities. If you are a customer of a company like Red Hat, does it really matter that you have access to the source code, or that you can share the software with others? Aren’t customers, in some sense, paying us to “just take care of all of that stuff?”
This line of thought is not original, but it’s one I’ve had for a long time – and others such as Simon Phipps have given voice to similar insights in the past. Hopefully I can give it a fresh treatment for Red Hat Summit attendees next week!
May 27, 2013
openstack, red hat
With my colleague Keith Basil, the OpenStack product manager here at Red hat, I will be giving a “webinar” about OpenStack, and Red Hat’s community-driven distribution of it, RDO, this Wednesday at 3pm UTC (5pm CEST, 11am EDT, 8am PDT, other timezones). We will cover what OpenStack is, at a high level, why Red Hat cares about it, and what RDO brings to the table.
Register to attend – I’ll see you there!
April 26, 2013
You: “I’d like to install a file server for the LAN – can I have the root password for the server, please”
Admin: “You’re kidding, right? Submit a ticket, we’ll install it when we get around to it”
You: “I installed a Samba file server for the LAN on my own Linux machine”
Admin: “Gah! You messed up my workgroup. What happens when you turn it off? Bloody amateurs…”
You: “I’d like to install a bug tracker for the dev team”
Admin: “The existing servers are overloaded – you’ll need a hardware req. Lodge a ticket, and get management approval first.”
You: “I’d like to install a bug tracker for the dev team”
Admin: “I’ll create a VM for you to use. Lodge a ticket”
You: “I’d like to install a bug tracker for the dev team”
Admin: “You have a self-service account on OpenStack, don’t you? What are you talking to me for?”
January 18, 2013
For anyone who saw the recent launch of the new oVirt website a while back and was wondering how we could make such an attractive theme and lay-out for a MediaWiki wiki, wonder no more. In fact, you don’t even have to be jealous! Because the theme, called Strapping, so called because it’s based on the Bootstrap web framework, has just been published by my colleague Garrett on GitHub.
Kudos to Garrett, who did amazing work on this theme to make it as beautiful and reusable as possible, and I’m looking forward to using it for other websites in the near future. And so can you!
December 21, 2012
The OSCON 2013 Call for Participation just opened and the list of tracks this year is mostly the same as last year. I am a touch disappointed, because I suggested to some of the conference chairs that a track I’d love to see, and which I think would get lots of attention, would be on how we grown-up hackers ensure that we’re growing the next generation of open source hackers. In other words, as a parent, tips on sharing our passion for technology and the open source, free software, hacker ethos with our kids.
This generally fits into the “Geek lifestyle” theme, which is the most marginal of the tracks, but I bet that if there’s a critical mass of quality proposals on the topic, that we could have a separate open source parenting track at OSCON – and it would be standing room only all week.
Some things I would love to talk about or hear people talk about:
- Hackable living space – teaching kids they can control their environments
- Preschool engineering – toys and games that teach your child to hack before they can walk
- My First Electronics Kit – How my son and I learned how to make a solar powered car from scavenged parts
- Teaching kids to hack – coding literacy in K12
And anything else which gives me ideas for projects I can do with the kids and their friends, or that I can bring to the local school.
Wouldn’t that be the coolest track *ever*? All it needs to happen is to totally blind-side the conference chairs with a dozen high quality proposals that no-one could possibly refuse! Who’s with me? Won’t somebody please think of the children?!?
November 27, 2012
Via Simon Phipps, I discovered PlayTerm this morning. You can record and play back terminal sessions, which allow you to show commands and their expected output, played at typed speed. This may be the greatest invention since screencasts.
« Previous Entries