Be Open from Day One

Karl Fogel:

At each step in a project, programmers face a choice: to do that step in a manner compatible with the future open-sourcing, or do it in a manner not compatible with the future open-sourcing. And every time they choose the latter, the project gets just a little bit harder to open source.

The crucial thing is, they can’t help choosing the latter occasionally — all the pressures of development propel them that way. It’s very difficult to give a future event the same present-day consequences as, say, fixing the incoming bugs reported by the testers, or finishing that feature the customer just added to the spec. Also, programmers struggling to stay on budget will inevitably cut corners here and there (in Ward Cunningham’s phrase, they will incur “technical debt”), with the intention of cleaning it up later.

Thus when it’s time to open source, you’ll suddenly find there are:

• Customer-specific configurations and passwords checked into the code repository;
• Sample data constructed from live (and confidential) information;
• Bug reports containing sensitive information that cannot be made public;
• Comments in the code expressing perhaps overly-honest reactions to the customer’s latest urgent request;
• Correspondence among the developer team in which useful technical information is interleaved with personal opinions not intended for strangers;
• Licensing issues with dependency libraries whose conditions might have been fine for internal deployment (or not even that), but aren’t compatible with open source distribution;
• Documentation written in the wrong format (e.g., that proprietary internal wiki your department uses), with no easy translation tool available to get it into formats appropriate for public distribution;
• Non-portable build dependencies that only become apparent when you try to move the software out of your internal build environment;
• Modularity violations that everyone knows need cleaning up, but that there just hasn’t been time to take care of yet;
• Need I go on? Do some of these sound familiar?

...

“In the open” means the following things are publicly accessible, in standard formats, from the first day of the project: the code repository, bug tracker, design documents, user documentation, wiki, and developer discussion forums. It also means the code and documentation are placed under an open source license, of course. It also means your team’s day-to-day work takes place in the publicly visible area (except for sensitive configuration data and the like — that of course stays behind your firewall).

“In the open” does not have to mean: allowing strangers to check code into your repository (they’re free to copy it into their own repository, if they want, and work with it there); allowing anyone to file bug reports in your tracker (you’re free to choose your own QA process, and if allowing reports from strangers doesn’t help you, you don’t have to do it); reading and responding to every bug report filed, even if you do allow strangers to file; responding to every question people ask in the forums (even if you moderate them through); reviewing every patch or suggestion posted, when doing so may cost valuable development time; etc.

Think of it this way: you’re open sourcing the code, not your developers’ time. One of those resources is infinite, the other is not. You’ll have to determine whether engaging with outside users and developers makes sense for your project or not. In the long run it usually does, and later posts here will talk about how to do that. But the important thing is, it’s all under your control. Developing in the open does not change your degree of control over the project, it just ensures that everything you do is, by definition, done in a way that’s compatible with being open source. And you get that for free.