Creating an Open Source Project
Recently, I announced on Twitter that I had started an open source project for a piece of software that I created (more on that later and in future blog posts). My original intent was to offer this software via a commercial license only (closed source), but as time went on I decided to share it as open source. In some ways this means abandoning all hopes of garnering license fees for the use of my software, but in other ways it means the following:
- The building of a community
- Greater exposure
- Lower barrier of entry
- Easier for developers to try the software
- Reduced risk if my little software company goes belly-up
- Infographic: Challenges in Managing a Hybrid Cloud
- Book Expert: Advanced Analytics with Spark: Patterns for Learning Data at Scale
- Agile Desktop Infrastructures: You CAN Have It All
- Mobile Content Management: What You Really Need to Know
All of these represent benefits to those who use open source software, and it could represent real monetary value to those who create it. This can be in the form of donations, consulting fees, service contracts, partnerships, or high-level employment. Either way, creating an open source project can generate opportunities for everyone involved; more so than if the software sits dormant on a hard drive somewhere. But where do you start?
Open Source Considerations
First, you need to consider the license you wish to use. This is an important choice not only because it dictates how your software can be used, but because it protects you as well. For instance, say you decide you want to "gift" your software to the world, and provide it free from any license terms or cost as public domain. This is very gallant of you, but it may leave you at risk if your software is used in some way that causes harm, or if someone accuses your software of malfunctioning. At the very least, you should enforce a license agreement that limits your liability, such as the MIT license, one of the BSD licenses, or the Apache license.
More restrictive licenses, such as GPL, have terms that make the license viral. This means that the terms of the GPL license apply to the software that derives from or even uses other GPL-licensed software. This is known as a "copyleft" license, and is a not a permissive free license like MIT, BSD, or Apache. Although the spirit of the GPL is to promote free and open software use, it does support commercial redistribution of GPL works under certain conditions. You should read the license for details.
All of these open source licenses, even free permissive licenses, contain language that limits your liability in the event that your software is thought to have caused some harm, in some way. To me, this was a very important fact to learn and remember throughout the open source process. Next, you need to decide where to host your project. Like open source licenses, there are many choices here. Factors that affect your decision include:
- Terms and conditions
- Open source license support
- Source repository support
- Language support
- Ease of use
Popular choices include the Google Code Project, SourceForge, GitHub, CodePlex, Gna!, or BitBucket. Some restrict the license terms (i.e., Gna! is GPL only), while others restrict SCM (i.e., GitHub supports Git only — duh), and some are generally platform-specific (i.e., CodePlex by Microsoft for .NET projects). SourceForge and Google Code both block access to US-sanctioned countries (i.e., Iran, N. Korea, and so on), while others such as GNU Savannah do not, in the spirit of open access.
All of the services have restrictions of some sort, such as the amount of free storage, number of committers, provisions for private versus public projects, and so on, all of which you should consider before choosing. I personally opted for Google Code project hosting, as it supported a wide range of licenses, as well as Subversion, Mercurial, and Git repositories. It uses your GMail account ID as the login and email for communications, and since I already have a GMail account, this made the choice easier. Additionally, you can have up to 25 projects associated with each GMail ID, each up to 5GB in size, with very few limitations from there. Check out code.google.com to see if it's right for you. Just to be clear, I have no affiliation with Google or the Google Code Project, in any way whatsoever. I simply chose it because it met my requirements and allowed me to use my GMail ID.
Other considerations include the source code repository (as mentioned above), support for comments and discussion threads (forums), memberships with privileges (i.e., committers versus read-only users), site restrictions (i.e., does the host site claim to own the code in any way?), and the use of other software within your project. For instance, do you require or even include libraries with their own license terms? Do they match your license? Are you allowed to use and distribute them in an open-source project? You may need to contact the library author(s) to be sure.
Finally, make sure you add the appropriate comment header block to each file you post as part of your open source project. It should reference you via a copyright notice, the license terms, and "freedom from liability" clause. For example, I chose GPL v2, and this is the comment block I added to the top of each of my files:
/* * This file is part of * * Copyright 2010-2013 <Your Name or Company Name>. All Rights Reserved. * <Your Web Site Address, If Applicable> * * is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, version 2 of the License. * * is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with . If not, see <http://www.gnu.org/licenses>. */
Again, this is just a suggestion based on decisions I made. You should do some research and ensure that your file headers match your license terms.
My Project: JetStreamQ
For my open source software, I chose the Google Code Project, with GPL v2 licensing, and the SVN repository since it integrates well with most IDEs. I happen to prefer NetBeans, but it should work well with Eclipse, or any language or environment via other tools such as TortoiseSVN, uberSVN, or VisualSVN. Next, I added some basic documentation, uploaded the source code including the NetBeans project files, as well as a bundle that includes the binary files, license terms, and startup scripts.
You can check out my project at http://code.google.com/p/jet-stream-q. Specifically, the project is a Java Message Service (JMS) implementation (not 100% compliant) that supports enterprise messaging including clustering with no configuration required. It also has no dependencies on other JAR files besides the Oracle JMS API JAR, and is comprised of just one JAR file itself. Simple and easy to use, with no time wasted making it work. These were two very important items on my wish list of the perfect JMS provider, so I built one myself to meet them.
If you've read my articles and blogs here on Dr. Dobb's, you probably know that I have quite a history working with and writing about distributed systems that require enterprise messaging in some form. This software represents my passion and research on the topic. Making it available as open source only furthers my desire to share my learning with as many people as possible. Over the course of the next few blog entries, I'll explore some of the internals of JetStreamQ, and the design decisions made in the course of its development. It consists of multi-threaded, enterprise-grade, mission-critical Java networking code with lots of data structures, all of which should prove interesting reading material. I hope you enjoy it.