• Releasing Code

last modified April 24, 2016 by strypey

Steps to Creating An Open Source Development Community

1) Decide on a decision-making process

Most open source communities begin informally and operate by the creed of "rough consensus and running code". Usually, in the beginning, decisions are made by a solo lead developer or a established co-op of collaborators. However, consensus can mean many different things, and larger projects often find they need to define their decision-making procedure more carefully, or change it to keep pace with their growth. Another consideration is who will own the rights to the code? The individual contributors, or a registered entity like a company or non-profit incorporation.

An open source community can choose to use majority voting, including proxy voting, or even elected representatives. It can be ruled by a benevolent dictator (eg Linus Torvalds in the case of the Linux kernel). The other point to keep in mind is that you can use one set of decision-making procedures for technical decisions about the code itself, and another set for making other decisions about the administration of the community. Decision-making models are as numerous and flexible as open source code itself.

Don't get too hung up on this. Like your code, it will evolve as the project develops. However, since you have a number of decisions to make in the next few steps, and you need to define what the "official version" means, and who gets a say in that, it does pay to give it some thought and discuss it with your group. 

2) Choose a license: copyleft (eg GPL, APGL, LGPL) or non-copyleft (eg Apache 2.0)

The choice of license depend on both your group philosophy on why you want to release the code, and how you intend it to be used.

A decision tree would ask a series of questions.

1) non-copyleft or copyleft?
non-copyleft: you simply want to make the code available, for any purpose, under very few conditions
  • 2) Do you want to take steps to prevent your source code being used as part of the basis for a software patent litigation? (copyleft licenses all take as strong a stand as they can against software patents )
    • yes: Apache 2.0
    • not worried: "MIT License" (X11 or Expat) or "BSD License" (Modified or FreeBSD)
copyleft: you want to create a commons that others will draw from and must offer improvements back to if they publish their changes
  • 3) Is the software you wish to release under a copyleft license a:

    • client-side application (programs that run on a desktop, laptop, or mobile device): GNU GPL
    • server-side application (programs that run on a remote server, accessed via a network): GNU AGPL
    • software library (code implementing a function or set of functions usable in other programs)
      • there are few or no other libraries that implement the same functions and you'd like programs to use a copyleft license if they use your library: GNU GPL
      • there are proprietary libraries that implement the same functions, so you don't mind your library being used in proprietary programs, so long as distributed modifications to  the library itself are released as copyleft: GNU LGPL
Client-side Application
Server-side Applications
 Software library   Patent-resistent  Patent-agnostic
GNU GPL GNU AGPL Want users to make their program copyleft to use it
 OK with it being used by proprietary programs  Apache 2.0   "MIT License" (X11 or Expat)

* A GPL license, for example, obliges anyone who publishes or distributes changed or improved versions of your code to allow those changes and improvements to be backported to the official version - if the maintainers so choose. 

* Under an Apache license, people can do pretty much anything with your code, including build proprietary packages around it. (The only thing they have to do is give you credit for the use of your code). The only thing they can't do is stop other people using your code, pass off their modified version as your version, hold you liable if it breaks something, or doesn't work how they want, or sue people for patent infringement for using your code.

3) Ensure that all copyright holders agree with the choice of license.

Under most copyright law, anyone who writes code retains rights to their contributions, unless they are commissioned to write that code by another person or organisation (who then owns the rights), or they agree to assign their copyright to another person or organisation.

4) Choose a name and logo for the project.

It needs to be a name that is not in use by any other IT company or organisation to avoid both confusion and potential Trademark litigation. Beyond that, you can call if pretty much anything you want. Some projects go for descriptive (Linux MultiMedia Studio) while others go for poetic (Haiku) or recursive (GNU's not Unix, WINE Is Not an Emulator). Most projects usually also have a logo.

5) Choose a development model

This builds on the choices you've made about decision-making models above. You need to give some thought to how your open source community will do its work.

* Will development be limited to a core group, or can anyone join? 

* What tests of trust will people need to pass before they get 'commit' access? 

* Will you maintain one stable codebase only, or will there be experimental/ testing branches? 

* Will the code be divided into modules, which can be developed somewhat autonomously by different lead developers?

* What version naming schema will you use? Common schemas are 'year.month' (eg Ubuntu 11.04), or 'x.y' where x is a milestone, and y is an incremental update (eg Firefox 4.0)?

6) Set up a publicly-available hosting repository for the official version

You can do this by exposing your existing repository to the web, or by cloning to a free code host like GITHub, BitBucket, or Sourceforge,. With the appropriate security, you can choose who has 'commit' access to the official version. Most open source projects register their project name and logo as Trademarks, so they can't be used by developers of non-official variants ("mods", "distributions", or "forks") without permission from the project maintainer(s).

7) Announce that you have released the code

Once you have defined your decision-making process, achieved agreement on a license, chosen your name and logo, defined your development methodoloy, and set up your repository it's time to announce your project to the net, via geek news sites like Slashdot and Reddit etc and social media sites running GNU Social, Diaspora, Hubzilla, Friendica etc. You may also wish to submit your project to the Free Software Directory and other similar directories.

8) Start refactoring your code

Source code written by an individual, or a group who work closely together, often embeds many hidden assumptions. Publicly releasing code usually requires a refactoring process to lower barriers to entry for new contributors.  This can be just a matter of making sure the code is thoroughly commented, but can also involve breaking the codebase into modules which can be developed independently, or swapped out for modules from other projects if they implement the same function more efficiently. Chunks of code which are frequently used, or potentially useful in other projects, can be made into libraries.

9) Build documentation for both end users and other developers

An online wiki engine such as WikiMedia is a the default choice for hosting this, and allowing community members to build it together. There are also newer collaborative authoring platforms emerging at present based on GIT, the distributed version management system created by Linux author Linus Torvalds.

Further references: