56

I have developed a fully functional tool which I would like not only to share with anyone interested but also get support from the community. This tool is cross-platform, written in C++ with Qt, the code is well commented but I still lack any documentation. There are also some small issues and improvements to be made before I can call it a stable, final version.

What are the first steps that I have to take to release code as open-source and attracting people interested in contributing?

This is my first serious attempt to release open-source code and I really don't know where to start. Should I just push it to Github put together a small wiki and pray for the best?

Improve this question
3

4 Answers 4

Reset to default
63

Choose your licence

If your code has been closed source up to now, the first thing you should do is decide on which open source license (GPL <=2, GPL 3, LGPL, BSD, Eclipse etc.) you want to use.

There are pro's and cons to each, so read up on what restrictions they place on the code and decide who you want to be able to use it. Warning, whichever you choose someone will complain - this is holy war territory, and beyond the scope of this question.

  • A great resource for determining which license is the right license for you is the very comprehensive, interactive license differentiator, from Oxford Universities OSS Watch.

Sanitise your repository

If the code in your repository doesn't already have your chosen license applied to it, I would go through your entire revision history so far and retroactively apply it (this may require a re-base at every point where a new source file is introduced). This will, however produce a nice clean repository which, when you release it to the public, has no revisions where your chosen licence isn't in force.

Another option is to start your public repository at the point of your first release, with minimal or no history up to that point.

This has the disadvantage that people can't go back through your history and work out how you got to where you are today, but it has the advantage that people can't go back through your history and work out how you got to where you are today. *8')

When the company I work for made the software I work on open source, we started by only producing snapshots of the working directory at release points. When we moved to using public github repositories we started each git repo at the point that a plug-in was (or set of plug-ins were) moved out of svn, rarely including any history at all.

Consider a Dual License

If you think there might be commercial interest in using your software, but have an ideological preference for a restrictive re-use license such as GPL 3, consider offering dual licensing. Offering GPL 3 licenses for public download, and commercial licenses for a fee gives you the best of both worlds.

Doing this from the outset is likely to cause less friction than starting to offer commercial licenses later on. If your community becomes popular, people may accuse you of selling out if you weren't straight about the possibility of commercial exploitation later.

Consider a Contributor Agreement

If you ever plan to dual licencse, or simply want to to keep your codebase yours, you will need to either re-implement contributed fixes yourself or get contributors to assign rights over their contributions to you. Otherwise you will find that their contributions prevent you from releasing your codebase under other licenses.

The answer by Mason Wheeler to the question Does open source licensing my code limit me later? provides some good information on this and how the libsdl project used to deal with this problem.

Do be aware though that just as your choice of license may restrict the people and organisations who will use and contribute to your project, so will your choice of whether to have a contributor agreement. Some people will not be happy to contribute to a project which requires them to sign a contributor agreement.

Dual License Contributor Agreements

The Oracle Contributor Agreement (links are hard to see on that page) is a good template for a contributor agreement. It is also licensed (CC) in a way that you can modify it and re-use it.

Improve this answer
5
  • 2
    Added Dual License Contributor Agreements section which we have found useful.
    – gahooa
    Commented Mar 15, 2013 at 3:26
  • A contributor license agreement is the easiest way to prevent me from contributing to your project.
    – piedar
    Commented May 31, 2018 at 21:52
  • Fair enough, but I would be much more inclined to agree to a reasonable Developer Certificate of Origin. Most CLAs are 100% for the benefit and protection of the project, not contributors. If a project lacks the basic respect of inbound=outbound, I might as well fork and keep the patches to myself.
    – piedar
    Commented Jun 1, 2018 at 15:44
  • I'm sorry @piedar bit I do not see how this helps me improve my answer. My focus on CLA's is copyright assignment, not patent protection. If you wish to make this point about CLA's please write your own answer.
    – Mark Booth
    Commented Jun 4, 2018 at 10:10
  • Aha, I see now that you edited the answer to discuss pros and cons of a CLA. No further objections!
    – piedar
    Commented Jun 4, 2018 at 17:17
28

The answer by Mark Booth is excellent, but talks only about licensing/versioning, so I would like to add a few points on a more technical field which are the first (or not so first) steps for me when releasing open source code.

  1. Enforce style and readability. Nobody wants to contribute to a project where they need to spend months to understand the basics. And nobody wants to read and use code like this. If you want other people to contribute to the project, it would also be great to specify what are the style standards to use.

  2. Cleanup. Mark Booth explained why it may be annoying to let anyone access every revision and see how the project was made from the beginning. In the same way, you must get rid of large blocks of commented code before releasing it (which is bad practice in all cases), or remove the comments which tell about what was the modification, when was it done, etc. (which is an even worse practice).

  3. Ensure that your source code has enough testing. It is especially important in this context, since people will come without knowing in detail how your application is done and what are the caveats, and will try to modify it, eventually breaking code.

  4. Describe your project. The code may be great. If I don't have any clue about what application is about, there are few chances for me to contribute to the project.

  5. Describe what the contributors may do. Some open source projects are very close and will accept the contributions only after severe testing and reviewing and only if they think they need the contribution in question. In other projects, on the other hand, contributions are welcome. It is always nice to know what is the case in your project before starting contributing to it.

  6. Present it. See, jQuery website is well done, with professional design, high quality content, etc. It makes you wish to participate to the project. If on the other hand you have a slow, ugly website with content which suck too much, people would rather go and contribute to other open source projects.

  7. Add support tools. For example, bug tracking is not an option for a commercial project. Why would it be for an open source one? It may also help to know what are the points which need contribution. If I use your open source product, find a bug, go to the bug tracking website and find that the bug is #1 in the list, I'll be more motivated not only to solve it, but also to commit my changes.

Improve this answer
1
  • 1
    "Describe your project". Yes. Ask yourself what assumptions you make about the knowledge of the users (you could even document that), then check if your documentation meets those assumptions.
    – Jan Doggen
    Commented Sep 16, 2013 at 7:14
5

Build it and they will come.

If there is a need for your tool, people will find it through search engines and word of forums. It never hurts to make a few posts yourself in special interest forums relevant to the domain that your tool is in. If there are any, hop on an IRC channel with people of similar interests to let them know about it. Blog about it (if you have a personal blog). Essentially, the more advertising that you do, the better. Having said that, if there isn't a need, people just won't use it.

So in short, yes, push it to GitHub. Enable the issues feature so people can log bugs and a Wiki if your tool is complex enough to warrant it. Don't be discouraged if you don't get immediate hits. Sometimes OS tools can take a little while to gather steam (although some of them are a hit right out of the gate as well).

Good luck :)

Improve this answer
0
0

Before you look at the Other Advice consider:

Governance

How will your project be managed after you grant it to the community. The benevolent dictator model does work, but people will walk and fork if they dont get benefits from the code / project.

Code Ownership

Who owns the code is very important, as only the owners (in US Law) can take people to court to enforce copyright.

This is why the FSF tells contributors to grant ownership to them, and they in turn grant access to the code under the relevant licence (GPL, LGPL version 2.0 or 3.0).

Governance Organisations

I am not sure what is available in the PHP world, but there are a number of useful plaforms and ecosystems for code governance. Each with their own licence and governance structure.

Other Licence Considerations

Where will the code be used, who will re-deploy it, what are the current licences that similar and platform code are deployed under. All these issues provide guidance as to what licence should be used.

If there isnt already a community of interest that you can leverage it is very hard to have a successful project just by yourself.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.