Open source and the lone developer

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.

This entry was posted in Open Source, Software and tagged , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

4 Responses to Open source and the lone developer

  1. Chris Ward says:

    Even that rigmarole won’t necessarily keep the ‘lone developer’ out of the hair of the ‘global corporation’.

    Enough ‘lone developers’ collaborating might come up with a ‘stray-cat’ version of the ‘pedigree-cat’ IBM Websphere Software and put the source on SourceForge for all to take. And then there might be some challenging business questions to address.

    But I asked the Websphere salesman whether Websphere Application Server Community Edition threatened his revenue targets. He said it didn’t, and further he said that he was willing to put Websphere Community Edition CDs inside the Christmas cards he sends to all his best customers.

    Next time you meet a Websphere sales person, do ask him or her the same question, and put the answer here. I wonder if they all feel the same way.

    Traditionally IBM encourages its customers to Share their problems and solutions with each other; and that includes software they have created.

    So how does the ‘global corporation’ add enough value to justify its existence, to justify the salaries, dividends, and taxes it pays to its employees, shareholders, and governments ? Innovating, and working very hard to develop products and services, and deliver them to market, I guess.

  2. Chuck Allen says:

    While it isn’t a lone-wolf situation, I was having a a “choice of license” discussion just this morning with a group. They are looking at OSI’s “Simplified BSD” License to accompany distributables (http://www.opensource.org/licenses/bsd-license.php ). This is little more than “attribution” plus “no endorsement.” It basically allows anyone to do anything with the code as along as they retain the original copyright and don’t use the name of the copyright owner to endorse derivative work, etc.

    However, Simplified BSD likely doesn’t work and likely wasn’t intended as a contributor license in a collaborative situation. Apache or Eclipse look like contenders. I’d be curious how you or your blog readers would compare the two.

  3. Chris Ward says:

    Ultimately it comes to a matter of ‘commercial fairness’ (think Microsoft Windows and IBM OS/2) and ‘free speech’ (think Linus Torvalds and most of the software developed in universities around the globe)

    If you’re commissioning … or implementing … the software for a nuclear power station, or an air traffic control center, or any significant long-lived infrastructure like that, what will be uppermost on your mind ?

    WIll it be “Does it conform to specification and can I service it ?” Or will it be “What kind of licence does it have ?”

    There’s some kind of tension growing, between the ‘scientists and engineers’ who have one motivation, and the ‘salesmen and business managers’ who might have a different one. How to resolve it ?

  4. Chuck Allen says:

    Chris,

    I’m not sure I understand your point. You write about that in the context of the implementation of a long-lived, complex system “what will be uppermost in your mind”‘… “Does it conform to specification and can I service it ?” Or will it be “What kind of licence does it have ?”

    In the long-lived, complex projects you describe, these two aspects are intertwined. It is hard for me to imagine that requirements related to licenses (and things like code escrow for proprietary software) wouldn’t be upfront considerations formally specified in RFPs along with the functional requirements. While it might be that engineers don’t begin their evaluations of the suitability of particular software by diving into the fine print of licenses, there’s a good reason for someone in these selection processes to be scrutinizing licenses early on. You’d imagine that in many of these processes, formal evaluation of software wouldn’t start until an understanding of the license under which it was available was established.

    While it likely doesn’t resolve the “tension” between engineers and business managers, you’d imagine that less variety among open source licenses might be of some help in reducing the occasions where a focus on license issues gets in the way of focusing on functional suitability of software.

    A separate point I’ll add to this overall conversation is that it is not just a case of lone open source developers running a-muck with creative, one-off licenses. I recently did a post highlighting some of the variety within the licenses under which industry standards are offered:
    http://www.hrinterop.org/node/78

    There are some problems here. You’d think that most of the groups I mention in my article would be better off with something like the “simplified BSD” license. The extra restrictions in some of these licenses, don’t really add up to advantage in the marketplace or any meaningful protection of the standards.

Comments are closed.