It occurred to be this morning when I was stuck in traffic that although a lot has been written about open source development for communities, much less is out there for the lone developer. This is the person who labors along by him- or herself, writing code and letting the world use it. Why might they do this?
- They love coding and sharing that code.
- They want others to use their software, either because of its terrific value or quality.
- They could be self-employed and produce the code to use with customers.
- They want to learn new technologies first hand.
- They are between jobs and want to stay sharp.
- They are hoping to eventually establish a community of developers around the codebase but it hasn’t happened yet.
Here are some things to think about before you set out to do that solo open source project:
- Find out of it has already been done. If so, should you choose something else to do? Can you start with what has been written and extend it? If it is being actively developed, should you join the community of developers? If you do decide to move ahead, can you justify to others why they should use your implementation rather than the other?
- Think about the programming language to be used and the overall architecture and design. Some languages do things better than others. If you are learning a new language, it’s probably best to get warmed up doing one or two small projects before starting a big one. Though I practiced iterative development when I was coding a lot, I could still tell by looking at it what bits of code I had written when I was first coming up to speed. It’s not a sin to rewrite it later, but it is time consuming.
- The choices of language and technologies used are especially important if you are developing open source as a way to get your next job. While I know that many people still write in COBOL, it might be better to use PHP, Python, Java, or Ruby for the project. While you’re are it, make sure you learn about security, database access, and Web 2.0.
- Decide where you’re going to keep the code. Two popular choices are SourceForge and Google Code. Read the rules of the repositories and learn about the tools they use. This will affect some of the other choices you’ll need to make about how you develop the code.
- Pick your IDE (integrated development environment). There are many out there including, for example, the IBM Rational development tools. If you want to use open source, consider Eclipse or NetBeans. ActiveState’s Komodo has an open source editor that is cross platform but has a more complete for-fee IDE. Your choice will depend on what you know or want to learn, as well as the IDE’s support for the programming language and frameworks you plan to use. Eclipse and NetBeans are especially strong for Java, for example. Of course, old standbys like Emacs will more than get the job done.
- Decide on the open source license under which you will release the code. This decision may be made for you if you are extending an existing codebase or pulling in code snippets from existing projects. To be blunt, if you are using code licensed under some flavor of GPL, you will stay under some flavor of GPL. You should learn the differences among the BSD, Apache, Eclipse, and GPL licenses. You can see the licenses at the Open Source Initiative. Advice: choose a mainline license, do not write a custom license, beware amateur intellectual property “experts,” and do not be pressured by peers into picking one license or another. Think about who will use your code and how it will be distributed. This is not the place to get clever. Do a web search to learn more about licenses. Read several articles and don’t stop after the first one.
- As you develop the project, keep track of and document every bit of code that you pull in from elsewhere. Note where you got the code, what license and license version it used, and where in your project it went. Seriously, do this. It may save you huge hassles later on. Keep some sort of electronic log to store this information and keep copies in a safe place.
- Don’t wait until the code is 100% complete and perfect before you release it, but you should be proud of what you have done at the time you first make it available to others. It is better to release code with fewer features but also fewer bugs, than put out a huge drop that breaks in many ways.
- Let people know of your work when it is ready. This means using any news facilities your code repository provides. If you are doing a WordPress plugin or a FireFox extension, for example, use the websites for those platforms to advertise and make your code available.
- Be prepared to fix your code, and fix it fast, after you release it. It won’t be perfect, but people will work with you and give you the benefit of the doubt if you are responsive. You want to develop a community of loyal and thankful users, and that won’t happen if you publish the code and then take a one month vacation.
- Don’t expect to get rich, but if you want to use PayPal, for example, to solicit some donations, most people won’t mind. Just don’t be annoying or overly persistent about it.
- Finally, if you have a day job, make sure you know your employer’s rules about your developing open source code on the side. Some employers may completely forbid it, while others might just demand that you don’t distribute software that competes in some way with their products. Be smart about this. Ask your manager and perhaps a company attorney. It might not be a bad idea to get permission in writing.