Managing Open Source Contributions

Today, I noticed a Plone developer asking a question about galleries...

Anyways, that prompted me to talk about managing open source contributions. So let's move on to the meat of this blog post.

What happens to your open source projects

It's difficult for most people who open source and manage many projects to continue maintenance of them over time. Over time, your focus can shift to other problems. You may no longer even use the package you're supposed to be maintaining.

Complexity over time

Unless managed appropriately, open source projects tend to get more complex and less focused on the original goal of the project. This is what was expressed in the tweet above and I won't dispute the "over-engineered and ugly" comment very far.

A simple example of how this happens is from another one of my old open source projects collective.easyslider. Originally, the slider configuration probably only consisted of 5 options. Today, there are 25 different configuration options with a couple different ways to use it. Every option, feature, etc adds more code to maintain and adds to the complexity of the project.

How does complexity happen?

This usually happens because a user wants to implement their corner case and offers to implement the functionality into the core project. This sounds nice; however, it incurs maintenance and complexity costs.

I've also been paid as a freelancer to implement additional functionality into the open source projects I manage. As a free lancer, to keep the project focussed, concise and easier to maintain over time, consider shipping an extension of the original project that overrides/extends the features. You can even consider delivering fork of the project.

Just say no

Keep your projects focused and simple. Be okay with saying no to contributions. It's okay for people to fork and provide their own variant that implements their use-case.

Do not open source everything

Make sure to be choosey when deciding if you should open source something. Even if you do not mean to maintain an open source project for the general public, putting the repo public in your user github area might welcome a issue submission, direct message or email. Over time, this can be more messages, issues than you want to manage.

Where/how to host your code

If you're having trouble limiting your open source contributions, here are some tips:

• A good README: be up front, provide clear intentions of how the project might be supported
• Community github organization: For communities like Plone, you can contribute code to a community organization to help encourage the rest of the community to collaboratively manage the project. You can be up front that you are open sourcing it and with what intentions you have to continue working on it.
• Public github repo(issues disabled): tells consumers you are cool with open sourcing work but not interesting in maintaining a project around it.
• Github gist: another good way to share code without having to maintain a project around it.
• Private repo: if you have no interest in collaborating with an open source community.
• Github organization: if you choose to build a project around a github organization, that usually says you are invested in maintaining a community around the project. Be prepared to manage users, documentation, issues and packages around that project. Examples being Plone and Pylons.

Handing off/walking away

An essential part of managing your open source contributions over time is to be able to hand projects off to others. People you hand a project off to should:

• users of the project
• contributors to the project
• interested in keeping the project going

Looking back at the collective.plonetruegallery project, I haven't made a commit to it in almost 2 years. There have still been fixes and various contributions and people still use the package but I've been completely hands off for a long time.