Supporting an open source community

How does building software for an open source community compare to the commercial world? It has been three years since I started working on an open source project. Before this exciting work I spent ten years building commercial software and I can tell you that the differences are really big both on the final product and the way the product is being built.

Here at Jive we are very focused on solving business problems rather than building cool technical solutions just because they help increase our ego. A consequence of this philosophy is that the community feedback is key to building a successful solution. This is one of the reasons I would like to thank you all for helping us build Wildfire into the product that it is now: a successful product that is growing and becoming more popular with each new revision.

Now back to the initial question. Is it really that different to build open source software compared to commercial software? As I said the answer is yes and let me give you a concrete example:

There was a time when Wildfire didn’t have support for SASL and I have to say that I had no idea about SASL. Fortunately, there was a community member that provided the first implementation and that was a great opportunity to review his work to ensure quality standards and at the same time learn about the subject. Moreover, a few month later we heard that other community members were adding Single-Sign-On and also GSSAPI as SASLextensions. I said: Wow, this is great. The community keeps providing some cool new features that are much needed and I’m not an expert on this area.

It was clear to me that having a big community was much more powerful than just having several developers and a few product users. Another way to understand the difference is to split the question in two areas: 1) product quality, and, 2) product development and support.

Product Quality

Wildfire has an incredibly large community behind it and we can safely assert that, due to statistics reasons, the more people use a product the more chances a product has for maturing and becoming a solid solution. The number of downloads we are registering is immense and the number of problems we are receiving is proportionally inverse. Of course, this was not the way things used to be. I think that the key to becoming a mature product, in our case, was being strict in running automated or manual test cases before delivery code to the community. In addition, the number of setups that are out there helps ensure that someone has to have already used the software the same way someone else is doing it. In summary, the bigger the community the more chances a product has for becoming a solid product. Let’s leave the analysis of the reasons why our community grew out the way it has grown for another post.

Product Development

Supporting an open source community is radically different from supporting commercial companies. The first thing that an open source product has to build, besides the product itself, is a community. For that it is key to have a good site that allows community members to meet up, collaborate, share experiences, problems, etc… The second challenge is to organize your time so that you can keep thinking and implementing new product features or bug reports and answer questions posted in the forums. While building commercial solutions there is naturally a bigger distance between developers and end users and usually customer support handles customer requests. In open source products, the developer is much closer to the end users so it is always a challenge to focus on work and the community at the same time. I can tell you that this is a very hard challenge but it pays off at the end.

Wildfire 3.2.2 is out now and I guess that this long post is just a way to thank you all for building Wildfire the product that we are all proud of.