Rolling out your proprietary abandonware as Open Source

Thu 11 September 2008 | tags: Open Source, Sociology, -- (permalink)

So, your organization has decided to dip your toes into the Open Source thing with some software that is providing a bit of a financial drag, even though it is valuable to your operations, and you think there might be an audience out there to help you keep it up. This article describes some things I think you should think about when you start this endeavor.

In a previous article, I attempted to make a strong distinction between Open Source software and Openly Developed software — stating that having one property without the other is a guaranteed way to have a mess. Whatever your reasons for starting an Open Source project from your proprietary stuff, here are some things that I think should be the goals of the effort:

  • The software has an audience
  • The software has a vibrant development community
  • The software is unencumbered

Having an audience

Attention is the scarce resource of Open Source Software. As an Open Source Software purveyor, you must compete for the attention of those who might use your software, those who might help develop your software, and those who might use your software and pay you to add more capabilities to it. To be successful, you must do some of the same things you would do if you were trying to box up the software and sell it — fill a need, make people aware of your solution, and keep your customers happy. While the filling the need part is practically the same, the awareness and satisfaction parts of the equation are a bit different when it comes to Open Source.

Your software may already have a significant built-in audience. For example, if ESRI up and decided to make ArcView 3.x Open Source, I would guess that a large audience of users and a significant audience of developers would start digging in. Many folks have a clear self interest in keeping the project going with or without ESRI’s intervention, and that action would provide them with a way out. On the other hand, if the potential project is unknown, is just an internal bit of useful code, or is something new you are starting from scratch, it’s going to be tough.

The first step to building an audience is stating in very clear, precise terms what the goals of the effort are to be. Successful Open Source projects are built around a clear problem that is to be solved rather than built around some code that solves a grab bag of problems or pretty code that doesn’t really do anything. If you can’t describe what the software does in a sentence or two, passersby aren’t going to give your project much attention. Clarity is also important because there are likely many other softwares out there that solve related problems. A smart Open Source user gains her leverage by gluing various bits together — allowing each component to do what it does best. If you software does a bunch of things incompletely instead of one thing thoroughly, you force potential users to spend a lot of time evaluating your software and how it can fit within the stack that they are building — adding overhead to their decision-making process and cruft to their system. Do (or aspire to do) your thing well.

Some examples of good geospatial Open Source project mission statements:

  • MapServer: rendering spatial data for the web
  • GDAL: translator library for raster geospatial data formats
  • OpenLayers: makes it easy to put a dynamic map in any web page

A concise mission statement signals to the market (your potential users and developers) that you have a well-defined problem, and more importantly, that you think it is solvable. Good mission statements are also relatively free from jargon and you could explain to a non-geo pedestrian what these projects do without too much effort. A strong Open Source development team spends a considerable amount of time arguing about the scope of the project and deciding how well new developments fit within the mission.

On the other hand, a wordy, jargony, mission statement is an anti-signal to your market that says your software requires too much attention to determine where it fits in their stack. Additionally, the wordy statement makes it clear that the scope isn’t very tight and that it might do a bunch of things poorly rather than one thing well.

Some examples of poor geospatial Open Source project mission statements:

  • PCL: a package of modules for rendering GIS data from a variety of backends into maps. Its mission is to be the best possible Python interface to open source GIS software such as PROJ.4, GEOS, GDAL, OGR, and MapServer, and to be easy to use with Python web application frameworks as well as with matplotlib.
  • Mapbender: is the tip of the iceberg, a meta layer of software providing access to the OSGeo SDI stack.
  • Majas: MAJAS is a component framework for building rich Internet applications (RIA) with sophisticated capabilities for the display, analysis and management of geographic information.

Developing a community

With a well-defined problem and mission statement in hand (maybe even some software that starts to solve or completely solves the problem too), it’s time to focus on developing a community around the software. Community in Open Source software revolves around conversation — active, like asking a question how to build the software on a mailing list, and passive, like a person totally unknown to the project reading a response to a question about how to build the software on a mailing list. A successful Open Source community has enough public communication to enable both the active and passive conversants.

A commonly observed paradox of Open Source states that the more bugs in the bug tracker, the better the software. It may seem counterintuitive that failing in public provides benefit to the project, but it does in a number of ways. First, it provides substrate for passive and active discussion — allowing the project to have history and (hopefully) demonstrate progress. Second, it demonstrates that the developers are responsive to the needs of users and other developers participating in the project, while lack of response and an appropriate license can often mean you’ll find your software forked. Third, participation allows people to have a stake in the project because without outside contributors, your project is pretty much dead.

Although it might not be a particularly apt metaphor, one could think of developing an Open Source community as planting a seed. Seeds (software) by themselves can’t really do anything without soil (bug tracking, mailing list, and source code management software), sunlight (a truly open license), water (communication), and fertilizer (outside contributors bringing new ideas). An successful Open Source project is unlike a plant in that its outcome is not determinant. You don’t know what your plant will look like or exactly what fruits it will bear, but you do know that without the proper conditions and inputs it won’t flourish.

Ensuring a fair game

Trademarks, licenses, non-disclosure agreements, copyright, patents — each of these is a tool that you can use to bludgeon your opponent or protect yourself (while bludgeoning your opponent :). These intellectual property instruments play a role in Open Source Software, and in fact the copyright-licensing duo are what allows Open Source to exist, but if you try to structure them for your project in a way that attempts to set your interests above other contributors or users, no one will come to play.

Choose a well-known OSI-approved license for your project. There are plenty of options for you to choose from, and they will allow you to get the protections you are looking for in a way that contributors can be comfortable with. In my opinion, software that is further down the stack (like a hardware driver or a file format reader) should have a liberal license (like BSD or MIT), and software that is further up the stack should have a more conservative one (like GPL), but choose what you think is right for you. Another rule of thumb is the larger the audience or installed base, the more conservative the license should be, but there are many counter examples to this heuristic.

Once you release a version of your software with a license, you can change it in subsequent releases, but that previous release is going to be out there with that license — to be possibly forked, embedded, and so on. If you aren’t quite sure, start out with a more conservative license and the relicense more liberally if you think you need to. To be able to relicense, you’ll need to be sure that all of the contributors who have copyright on the software agree to the change. One way to be able to do that is to have a contributor agreement that assigns the copyright of their contributions to an entity (similar to how the Apache Foundation Software works), or you’ll need to keep track of your contributors and get them to consent to the licensing change. Be ready to extract their contribution from the software if they don’t agree to a licensing change. In short, pick the right license from the start and don’t attempt to relicense. It’s just a big hassle

The steps to do it

Here’s a short list of things you should do in preparation for releasing your software.

  1. Read Fogel. My writing here is just a short and insufficient facsimile.
  2. Do market research. Is you niche already filled?
  3. Participate in another project. Learn best by doing and that experience will help guide you when you start your project.
  4. Comb through your code. Ensure you don’t have relicensed proprietary stuff, or things that are going to cause intellectual (patented by you, code that you do not own that is not able to be released) problems for you or your users once the code is released.
  5. Pick a good name. Don’t underestimate the value of a good Open Source project name. It needn’t be descriptive, but that property can help.
  6. Setup your infrastructure — Trac/SVN, GIT/HG, Mailman, etc. Copy successful project’s infrastructure, as they’ve likely spent a lot of time oscillating to get their infrastructure to where it is.
  7. Start developing publicly, but don’t make a big PR splash. Have your developers use the infrastructure for all of their communication about the project and resist the urge to make decisions in physical meetings. Remember, you want to be making history. If you try for the big PR splash too early, you might over promise and have a hard time attracting attention in the future.
  8. Federate the project. Build software hooks from your project into others. Ensure that your project can stand on the shoulders of others. This activity demonstrates you have a good grasp of where your project fits in the ecosystem, which niche you fill, and reinforces the mission statement.
  9. Be patient. The masses won’t come flocking. If you grow one active external developer every six months, your project is highly successful.
  10. Release early and release often. Releases are the signal to outsiders that your project is alive.
comments powered by Disqus