Why and how to start contributing to an enterprise open source CMS community

Open source communities rely very strongly on the community to advance the software in question. eZ Publish adds the "enterprise" part to "enterprise open source content management system" by not only targeting larger enterprises but by also adding a company vendor -- eZ Systems -- behind the software. This helps spur development forward on a consistent pace. However, there is still immense value in having the implementation partner companies contribute their code and insights. Contributing back might not be a natural thing for the partner companies to do; if you're such a partner company, here's why you should and how to do it.

The notion of "contributing back" can take many forms.  You could contribute to a public wiki, answer questions on forums, or write blog posts.  You could contribute socially by organizing and/or attending events, whether in-person or online.  You could contribute marketing expertise by promoting the community and the core software.  For the purposes of this post, we'll focus on contributing code in the form of publicly available extensions to the system and kernel contributions.

Why contribute

Contributing code is a learning opportunity: it forces you to dig further into the code base you're working with and to fully understand why your code works. It helps you to examine your code from a re-usability standpoint to see whether it could be used in other situations. By having the public look at your code, you get feedback from others as well as a chance to learn more about what they're working on. You will also get a good sense of who has experience with various issues, which will help you in the future when you come upon other questions and challenges.

Contributing code is a good marketing opportunity.  It helps to build your profile and credibility in the community in a general sense, but also in a specific sense when you can point current and prospective clients to your concrete contributions to their core software.

Contributing code is intrinsically rewarding. Developers enjoy seeing their work put to good use within client projects, but also get a huge sense of additional validation if their solutions are deemed "best practice" solutions that can be used by others.

Contributing code is good business.  It is an especially obvious payoff if you need to modify the kernel of the CMS and do not want to have to re-apply those changes upon every subsequent release of the CMS.

Common fears

What if your code isn't "good enough"?  Every project has time and budget constraints, and we all have to make certain sacrifices in terms of code elegance.  The truth is, most developers think that their code could and should be better.  In reality, if you're doing your due diligence to create solid solutions for your clients, your code is probably quite good.  If you release some of that to the public, you get a free code review and you might even get additional code contributions back from others that will help you on your next project.

Is your code a competitive advantage?  To some extent it is, but your "secret sauce" is more likely your people, your way of doing business, and your experience.  Plus, other partner companies on the same CMS are often not your direct competition; you have shared goals in terms of helping the CMS become better, raising its awareness in the market, and growing the general knowledge base.  You might even get more work as a result of being the expert creator of a piece of public code.

How to contribute

If the above reasons aren't compelling enough for you, you might still cite a lack of time as a reason why you cannot contribute.  Or, if you're used to closed source software, it might simply be an unnatural step for your business to contribute back. Here at Mugo, we discovered that a few small efforts made contributing back a simple and efficient part of our normal workflow.

Lead by example. Don't just tell your employees and co-workers that it is important to contribute code back.  Do it too, and tell them about what you're doing.  You'll discover how straightforward it is, and if there are any particular challenges, you'll understand what your peers are going through.

Make internal sharing a regular priority. For example, schedule a casual sharing time every week where people can demo something cool they've done or a challenge they're having. This can complement and spur other ad hoc sharing that happens, but also brings up a dedicated time to point things out like "that should be part of the core", "that would be a good general solution or product", and "that would make a great blog post".

If you're part of the eZ Publish community, start by exploring the share.ez.no forums and, if relevant, the eZ Publish Americas Meetup group.  To start contributing code, there is a detailed tutorial on how to contribute to the core.  It is also common and easy to host a public GitHub repo of extension solutions.  Then, tell everybody about what you've done on Twitter (use the #ezpublish hashtag) and Google+.