Scott Kveton

I’m often asked questions about open source via email from people all over the world. They are asking for my opinion but mostly because they don’t know where to start. If you’re new to open source and just looking into either joining or creating a community it can be rather daunting.

I met with Derek Abrams and he is asking these various questions. He distilled them down to two of the most important questions he wanted answered and I’m going to do my best to answer those here:

1) What are the differences in the license offerings?

Three words: can of worms. As of this writing, there are 58 OSI approved licenses that one can use to release their works as “open source”. The sheer volume of licenses makes even the most liberal lawyer (is that an oxymoron?) nervous let alone a person just entering into the open source space.

Most of the time, these open source licenses are much alike. Sometimes it can be as little as one or two sentences that differentiate them. In the case of public agencies, the use of the GPL might be impossible because they can’t indemnify themselves.

My recommendation to people on this subject is to stick with what works and is generally accepted: the GPL. About 70% of “open source” software is currently licensed under the GPL v2.0. Just because everybody else is doing it isn’t the only reason. To be able to point to so many companies and projects that are using this license it helps to put newcomers at ease (especially said newcomers legal department).

The only downer about the GPL is the impending release of v3.0 of the license. Some are saying their may be the “web services” clause included in this version. If that happens, there could be trouble for companies as this “viral” license may “infect” other parts of the organization and “force” the open sourcing of normally internal-only software. Will this happen? That’s what everybody is wondering. However, with an installed base of 70% I feel pretty confident that nothing too drastic is going to happen with v3.0.

My advice? Don’t try to make your own license; what you’re doing is so specific to your organization that you can’t leverage an existing (and hopefully really common) open source license. Go with the GPL.

2) What is the anatomy of an Open Source project?

This is a great question, IMHO.

First and foremost, you need to have buy-in from the players involved. If you have people who are even mildly tepid on the idea of doing an open source project it most likely will not be successful. Buy-in from your hosting organization (say your public institution or company) is critical. It never hurts to run these things up the flag pole. The people you work for never like to be surprised.

Choose the GPL or another well-known open source project if you’re starting from scratch. See 1) above.

At the core of an open source project are the things that make it easier to collaborate; the tools. Wiki’s, forums, mailing lists, IRC, etc are the plumbing required to execute any distributed development. These are almost to the point of being a commodity although some projects still have trouble providing these services. For most open source projects, even deploying these services can detract so much from the projects “main thing” so as to severely hobble a projects progress.

When in doubt, collaborate first. I’m sure the idea you have come up with is a great one. But searching on the Internet will most likely reveal a similar project. Find ways to collaborate and give it a little more than the ole’ College try. Any issues you might have with an existing project will most likely surface with your project down the road. How will you be prepared to collaborate with other people when they come knocking?

Leadership within an open source project is critical. Some people call this the “benevolent dictator” and a great example of this is Linus Torvalds or Jimmy Wales (from Wikipedia). Both Linus and Jimmy are very good at working with the community, delegating and dealing with grievances in an open/transparent fashion. The fact is, if you’re a jerk in the community, you’re going to fail as a leader. Understanding that you’re not always right is a hard lesson (albeit extremely valuable).

You could do this by committee. Some projects do this. However, when conflict comes up or a hard decision needs to be made (and this does happen) you get nothing but death by committee.

Open, honest and transparent communication is very important. Bejamin Mako Hill has written a really good article on why you have to be transparent. This is a great read for anybody considering starting their own project from scratch and looking at either volunteer or paid developers to help make it happen.

The license, the buy-in, tools, transparency and leadership are all about building a sustainable community around your project. The goal of any project leader should be that they can walk away and have the project stand on its own. This is the mark of a trully vibrant and effective community and project and every project leader should strive for this IMHO.

The OSL is participating in a community source FIS system for higher education. The idea of community source is that you collaborate with institutions on the rapid development of some application by committing resources and holding people accountable. This is a great formula for shortening the transaction time for open source. However, community source is the subject of an entirely different posting …