The WSO2 Approach to Creating and Managing Content for Open Source Products

“Just open, honest communication is the best thing in the world” (Brett Davern). I was delighted when I stumbled upon this quote, because it sums up our approach to technical content at WSO2. There are plenty of advantages to open content: driving adoption and expansion, improving content quality via better feedback from users, and increasing successful usage of our products. You may wonder why we make our documentation and even our training content publicly available for free. After all, support is an integral part of our business model, and it contributes to a sizable percentage of our revenue at WSO2. What we have discovered is that high-quality, freely available content does not deter users from buying support. For customers who are building mission-critical solutions, support is essential to receiving timely responses to problems they may be experiencing, whether it’s a bug in the code or a question about the best way to solve a particular problem. One of the primary advantages of open content is that it drives adoption and expansion. Our goal is to have as many users as possible, and when our documentation and training content is freely available, users have a better opportunity to get up and running with our products quickly and effectively. As they learn ways to solve their business problems with our solutions, people discover more of our products and features that can be used to solve other problems that they envision. Another major advantage is that open content helps you to improve content quality. More readers mean more feedback. At WSO2, we take it one step further by making the documentation available during the development process itself to ensure that we receive feedback during the entire content release cycle. Getting user feedback early helps us immensely in the planning stage to make sure that issues of concern are addressed in our next release. When developing training content, we point to the documentation for much of the conceptual information, so that as you learn to use the products during training, you become thoroughly familiar with the documentation as well. This approach allows users to easily go back and find information after they’ve completed the training. We’ve also discovered the following best practices for creating content for open source products:

• Categorize the content types - at the beginning of a release, plan not only the documentation and training content for each new feature but also what would work best as technical articles, blog posts, or marketing content.
• Write for a wide audience - open source products have wider audiences, many of whom are non-native English speakers. Use clear, concise language and include a glossary of terms.
• Test and review on multiple platforms.
• Engage the community - introduce simple processes for contributing, develop reward systems, build relationships with users, and recognize people’s strengths to maximize contributions from a wider community.
• Release documentation at each milestone to encourage timely and ongoing feedback.

When your content is ready for distribution, there is a range of platforms you can use. We primarily use Confluence and GitHub at WSO2, but some other platforms we’ve been researching are ReadtheDocs.org, Mkdocs, and Asciidoc. To learn more about these platforms, best practices, open source content licensing, and detailed advantages of open content, check out my webinar on creating and managing content for open source products.