FLOSS Foundations

April 18, 2014

Dave Neary

Project naming

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

  1. Start with a concept and work from there. Break out the Thesaurus, make a list of related concepts.
  2. 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.
  3. Keep the shortlist to names which are short and pronounceable in multiple languages.
  4. Cull ruthlessly – don’t keep “maybe” names. If you get to the end, go back to the concepts list and start again.
  5. 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!

by Dave Neary at April 18, 2014 09:21 AM

April 17, 2014

Dave Neary

Choosing a license

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.

  1. Does the project exist as part of a greater ecosystem (eg. Apache, Eclipse, GNOME, Perl, Ruby)?
  2. 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.
  3. 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
  4. Do you want to grow a vibrant developer community around your project? If not, why not? Avoid dual license, copyright assignment
  5. 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
  6. 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
  7. 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
  8. Do you believe that all contributors to the project, including extensions, should be subject to the same rules? Choose GPL v3
  9. 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
  10. 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!

by Dave Neary at April 17, 2014 09:31 AM

Writing more

I realised recently that most of my writing has been of the 140 character format recently…. I plan to rectify this, starting today.

by Dave Neary at April 17, 2014 09:06 AM