You are here: Home Articles The dog ate my contributor agreement
Navigation
OpenID Log in

 

The dog ate my contributor agreement

by Martin Aspeli last modified Dec 12, 2009 09:47 AM

Top five excuses for not contributing to open source, and why you need to get over it.

Plone is true "community-driven" open source project. No-one is paid specifically to work on Plone, and yet it gets developed. The Plone Foundation protects Plone's intellectual property and handles other issues (like commissioning marketing materials and managing domain names), but takes a completely hands-off approach to development. And yet Plone development continues apace. No one company has a monopoly on development, and yet many small companies and individuals manage to self-organise into building the content management system you know and love (or love to hate).

How does this happen? How does the content management system, which you are implementing for your business or selling to your clients or using on a day-to-day basis, come to be?

Contributors, that's how.

That's right, open source software is built by contributors. People who write code and documentation, who test and report bugs, who evangelise and organise conferences and other events.

But who are these mythical contributors? By and large, they're people like you and me. They have needs to solve. They have projects to deliver. They have customers with requirements. And they have found out that by contributing to the project, they gain something.

There are several reasons why people contribute to open source (some of them outlined in my Master's thesis), but here are some of the most important ones in the context of Plone:

  • You are using Plone and you find a bug. You report that bug. (This is already a form of contribution.) Your problem is solved if and when someone finds the time to fix the bug. If you're lucky, you may know someone who can fix it for you quicker, or you may pay someone to fix it if it's urgent.
  • You are using Plone and you find a bug. Instead of (or in addition to) reporting the issue, you submit a patch (in the issue tracker) or commit a fix. You gain almost immediately, because your problem is resolved. Other people gain too, because they get your fix in the next release.
  • You are using Plone and you need a new feature. You write it, either as a change to the core of Plone, or as an add-on product. You release that so that others can benefit. You gain, because other people may help you maintain the software, by fixing bugs or contributing improvements.
  • You are using Plone and you need a favour. Others have benefited from your contributions previously, and all are all too happy to help answer your intricate questions or debug a problem. You gain, because you can call in your favours when you need them the most.
  • You are using Plone and you want to get better at it. You make a contribution. In the process, you ask for some advice (or receive some unsolicited). You learn and become a better Plone developer in the process.
  • You are using Plone and you contribute a high-profile add-on product. People realise you're good. Your services come in demand. Publishers want you to write books. You find that you can make good money as a Plone consultant. You gain because your marketing budget is naught.
  • You are using Plone and it is an important part of your business. You contribute new features and participate in the community processes (like the Framework Team), as well as in the general discourse on the mailing lists and chat rooms. You gain because your voice is heard and you are given the chance to influence the direction in which Plone is heading.
  • You are using Plone and you go to a conference. You meet lots of people there, who you come to call your friends. You gain because you make new friends. Bonus if you didn't have any to begin with.
  • You are using Plone, and you've previously fixed bugs and helped others. You go to a conference and meet the people who've benefitted from your work. You are filled with a sense of great accomplishment and pride as they thank you sincerely. They buy you a beer. You get drunk, and decide to hit on the hot blonde who happens to be in the bar and loves your Star Trek t-shirt. You gain because... oh, nevermind.

Contributions don't necessarily come in the form of code either. Some of the more valuable things you can do are:

  • Answer questions on the mailing lists.
  • Test new releases and report bugs.
  • Help translate Plone to your native language.
  • Help organise the bug tracker, combining duplicates and filtering out invalid bugs.
  • Write documentation, whether for end users or developers.
  • Organise a sprint, symposium or conference.
  • Sponsor important work.

Contribute, moi?

Everyone, without exception, has the capacity to contribute. And yet, many are apprehensive. Let's count down the most common excuses.

1. I have no time

Guess what, no-one else has any time either. Not one single person is paid specifically to work on Plone. Do you really think that you are so much more busy than everyone else?

This is of course a very valid excuse. Plone shouldn't come at the expense of your personal life or client deliverables. But this is not a zero-sum game. Time spent contributing has benefits. The smart Plone companies have realised that they owe their business in part to the community of contributors, and need be a part of that to stay relevant, to improve their standing in the market, and simply to have a platform to build on in the future.

Find out how you can contribute, and take it seriously. Many Plone companies have vowed to spend 5-10% of their time on community contributions. One way to do that is to send people to conferences and sprints where they can connect with others and work on Plone core.

Furthermore, the best Plone companies will find ways to improve Plone in the course of their customers projects, for example by writing re-usable components instead of "point solutions" where possible. Customers benefit here too, because they end up with more maintainable software that is understood by a larger community of vendors. The solution that is cheapest in the short term is rarely the cheapest over the total lifecycle of a project, and vendor lock-in (even to a vendor as nice as you and your company) is a risk not to be taken lightly. It's pretty likely that your customers chose open source and Plone at least in part for these reasons, so don't be afraid to make the case that contributing to the community makes sense for them as well as for you.

2. I am not good enough

Trust me, if you know where to look, you'll find code in Plone written by programmers way less skilled or experienced than you.

This is probably the most common excuse, but it doesn't hold water. Everyone can contribute, and writing code is far from the only thing that is valuable. You are never going to get better unless you try. Perhaps you shouldn't try to perform major refactoring or change any fundamental behaviour the first time around, but bugs are fair game, and Plone has a well-established process for reviewing proposals for new features.

More importantly, you'll find that if you try to contribute, you will get a lot of help and kudos. Existing contributors are much more likely to help those who try to help themselves than those who throw up their hands and say they can't or won't (but still complain about bugs going unfixed). Ask in the IRC chatroom or the on the mailing lists. Make it clear that you're trying to do your bit. I for one will help you if I can. And before you know it, you'll be the one helping others get their contributions in. We all started somewhere.

Plone in particular has a low barrier for contributions. There are people who read the checkin mailing lists and will email you if you did anything wrong. In the words of Plone's co-founder Alexander Limi: It's better to ask for forgiveness than permission.

3. I need a fix RIGHT NOW

We have a tool for you: it's called Subversion.

Some people seem to think that getting a fix into Plone will take longer than doing it themselves, e.g. with a monkey patch in a separate product. This is entirely counterproductive. First of all, by keeping the fix out of its proper location, you create an additional maintenance burden. Secondly, you're likely to find yourself fixing the same thing again on your next project, especially if Plone has moved on and your patch is no longer 100% valid. Thirdly, fixing a problem with an override is almost almost more complex than fixing the original code. Finally, you are keeping others from benefitting from your changes, so you get none of the network effect benefits.

Fixing something properly is easy. Modern Plone projects are managed with Buildout, which in turn manages a set of Python eggs that make up the Plone distribution. All you have to do is check out a "develop egg" from Subversion for the package you need to fix. If you use the mr.developer extension, it's even easier, you can just add the svn path and run "bin/develop co plone.whatever". You make your fix there, and then commit (try to make sure the tests pass; you may also be asked to merge your fix to trunk if you're on a maintenance branch, but that is easy in almost all cases). Until there's a release, you'll need to keep running that egg from Subversion, but this is little different from running your own, unreleased/untested code.

Now, some people are nervous about running Plone packages form subversion. Luckily, the actively maintained Plone versions see a release every 2-4 weeks if there are changes to release. And since Plone is now just a set of eggs, you don't need to wait for a full Plone release. Ask the maintainer of the package you had to fix for a new release, and you can start using it right away with a single line in your [versions] block in your buildout.

In an case, the burden of fixing something "out of context" and managing that fix "forever" in a separate place is always going to be higher than doing it properly. You're also much more likely to get feedback and help from others if you contribute, so you'll know much sooner whether your fix is "right".

4. I don't want to (or my boss won't let me) sign the contributor agreement

This one falls into three categories: Some people hate paperwork and can't be bothered to sign a legal document; some people are uncomfortable with the terms of the agreement; and some people work in organisations who are too paranoid to have their employees sign an open source contributor agreement.

There's little excuse for the first category: Plone's contributor agreement is a two page form written in pretty clear language. I think it took me five minutes to read it, sign it, and send it off.

If you are in control of your business, you also have little to worry about. So many other businesses have signed up that you are unlikely to have a unique problem. The contributor agreement is there solely to protect you and others like you. It is not a legal document designed to take away your rights. Anyone who's been involved in an open source project where intellectual property issues became a real, rather than a hypothetical, issue knows that this is a murky world that can lead to a lot of confusion. You should be thankful that people have invested a lot of time and pro-bono work in helping the Plone Foundation set up a constructive agreement.

If you are being told you can't sign, at least try to make the case. Ask others how they've overcome such obstacles. Most companies have ways and means if you only try.

Finally, although Plone's contributor agreement covers the bulk of code in the Plone release, it is not necessary to sign one to commit code to the Collective subversion repository, or to contribute in other ways.

5. Someone else will fix it for me

In economics, this is known as the "free rider" problem. If we all had to pay the police directly for fighting crime, chances are an insufficient number of people would pay, since crimes prevented in your neighbourhood benefit you equally whether you paid the policemen who prevented them yourself, or only your neighbours did.

Some projects have attempted to address this in the same way that governments do when they tax citizens and use the revenue to fund public services (and duck houses): one company or organisation tightly controls development and charges some or all users of the software a fee to use the software or become certified solution providers. Some of that revenue is then ploughed into development.

Plone doesn't follow this model, and never will. You should be thankful. You have an opportunity to participate in a truly democratic process, to be part of a mature, open and friendly community, to have your voice heard and directly influence the future of the platform. You can bet your business on a technology, safe in the knowledge that many others have before you, and no-one can decide they want to squeeze you out of the market by denying your rights to the software. This is true open source. It's pretty amazing. You owe it to yourself to be part of it.

Document Actions
Plone Book
Professional Plone 4 Development

I am the author of a book called Professional Plone Development. You can read more about it here.

About this site

This Plone site is kindly hosted by: 

Six Feet Up