Saturday, March 4, 2017

Open source branding

I recently discovered this 2016 article from Opensource.com about branding in open source software. The article encourages projects to kill off extra brand names to help your project get recognized.

The article describes the issue in more detail, but here's a summary:
Let's say you are the maintainer for an open source software project, which I'll make up. Let's call it the Wibbler Framework.

Maybe this is a website builder. Developers can use Wibbler to create awesome, dynamic websites really easily. Wibbler is based around different modules that you can load on your website to do different things.

One day, you get a great idea for a new chart display component. So you spend the weekend writing a module that provides a super simple way for websites to display data in different formats.

You think the new module is pretty cool, so you give it a name: ChartZen.
Pretty realistic scenario, right?

But the problem is this: you've added an extra "brand" to your project. When new users find your project, they are confused. Is it Wibbler, or is it ChartZen? How does ChartZen connect to Wibbler? Do I need to get Wibbler if I just want to use ChartZen? Do I need to run two different servers, one to run Wibbler and another for ChartZen?

By adding the second name, you've confused the original project.

It gets worse if you continue to add new "branding" to every new module. If you continue to add new names for every new module, you end you with a confusing forest of competing "brands": Wibbler, ChartZen, AwesomeEdit, FontForce, FormsNirvana, DBConnSupreme, and Pagepaint.

It's better to just name each component after the main Wibbler project. Keep the Wibbler brand intact. ChartZen becomes "Wibbler Charts," which is easier to remember anyway. And it's immediately clear what "Wibbler Charts" does: it's a component for Wibbler that makes charts. Similarly, you also have "Wibbler Editor," "Wibbler Font Picker," "Wibbler Forms," "Wibbler Database Connector," and "Wibbler Page Designer."

How do you manage your open source software project's "brand"? Do you have different names for different components? Or do you maintain one core "brand" that everything connects to?

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.