Why We Only Develop Open Source Software



January 06, 2008

We've had a couple exchanges with clients lately where they wanted us to develop code for their Drupal site, but they wanted to own the code outright and not have it licensed under the GPL. I thought I would outline here some of the reasons why this is problematic for us and why it isn't part of our business practice.

The first thing is that realistically in most open source software if new features are developed they are rarely done from whole cloth. With Drupal, we might need as little as 200 lines of code for a new module. To save everyone money, increase security/performance and be able to give our clients the most functional site possible, we generally at least reference one or more existing modules and build on them. The new module could contain a significant proportion of code that was taken from another module (or combination of modules) and that was released to the community under the GPL. The code that we were hired to write may comprise less than 50 new lines. Never the less, this module would stand alone and would be able to do its unique function, but unless we wrote 100% of it from scratch we wouldn't be able to hand over full ownership of the code to you.

In most cases it is a much better programming practice to build on and contribute to existing software rather than writing everything from scratch. You get the benefits of being able to look at and improve best practices and also to have the new code evaluated by a community of developers. The other issue is that it is much more time consuming to develop the code without being able to review work that has been done previously.

We are an open source shop and are not set up to ensure that the software we develop for our clients are only to be used for that client. We don't like spending $$ on unnecessary legal fees (and don't want to become that way either), so we try to keep our approach to Intellectual Property (IP) as simple as possible. We don't want to open ourselves up to becoming involved in a legal battle because one of our developers reused some of the code we'd developed for you.

However, we don't formally release everything we develop. Usually this is because it is too specific to serve the general community, however we do sometimes delay releasing useful code we've written if it benefits our clients. If our clients are worried about competition we can agree to not release the code after a set period of time or agree not to work with a competing company. For the purposes of competition however, what is more important than the code we write is the recipe that we use to put together a given site (these are good examples of recipes emulating Youtube or Flickr's functionality). If the need is not to let your competition replicate your site, this kind of information is more relevant to people who are worried about competition than the code.

We do occasionally try to do things like this, but generally don't have time to do a nice write-up of our work and we certainly wouldn't do so if the client didn't want us to. The code we would be developing are for things that would be a minor change to the functionality of the site. Without the context I'm pretty sure it wouldn't pose a risk for competition. We could put that into writing if you like and could write up. Could also write up something to say we wouldn't set up a similar site for one of your competitors for a set amount of time.

About The Author

Mike Gifford is the founder of OpenConcept Consulting Inc, which he started in 1999. Since then, he has been particularly active in developing and extending open source content management systems to allow people to get closer to their content. Before starting OpenConcept, Mike had worked for a number of national NGOs including Oxfam Canada and Friends of the Earth.