Once a kind of counter-culture alternative to the commercial dominance of Microsoft, the open source movement has spread rapidly beyond its initial roots. Few now question offering an open source option as a valid go-to-market strategy, and many software vendors even use this approach to acquire customers through a freemium model.
One key to the success of these approaches is to offer a developer community. It is a great vehicle to increase brand visibility and reach end users.
But the journey toward an open source approach with a community to support it can be long and arduous. I’ll walk you through the steps we took at Quali to open up our integrations and talk through the role our knowledge sharing community played in supporting that transition.
Start with Culture Change
While it might seem straight-forward for most software engineers now, changing the mindset from a culture of privacy and secrecy to one of openness can be significant, depending on how long the company has operated or the background of the company’s chief managers.
Our company’s executives had experience in the conservative world of the Air Force and electronics. With that mindset, the shift to offering an open community to encourage open source integrations did not happen overnight.
In fact, it took us about three years to get all the pieces off the ground and get the entire company aligned behind this new paradigm. Eventually, what started as a bottom-up, developer-driven initiative, bubbled up to the top and became both a business opportunity and a way to establish a competitive edge.
The driving force: We’re a startup, so we can only put so many resources behind the development of custom integrations. As an orchestration solution depending on a stream of up-to-date content, the team was unable to keep up with customer integration demands.
The only way to scale was to open up our platform to external contributors and standardize through an open source model (TOSCA). Additionally, automation development was shifting to Python-based scripting, away from proprietary, visual-based languages. Picking up on that trend early on, we added a new class of objects (called “Shells”) to our product that supported Python natively and became the building blocks of all our content.
Look for Inspiration
We started exploring existing examples of communities that we could leverage. There is thankfully no shortage of successful software communities in the Cloud and DevOps domain, including AWS, Ansible, Puppet, Chef, and Docker.
What came across clearly? A developer community isn’t just a marketplace where users can download the latest plugins to our platform. Even if it all started with that requirement, we soon realized this would not be nearly enough.
Group Components Together for Maximum Effectiveness
What we really needed was to build a comprehensive, “one-stop shopping” experience. We realized that a technical forum, training, documentation, an idea box, and an SDK that would help developers create and publish new integrations.
We had bits and pieces of these components available to internal authorized users, and this was an opportunity to open this knowledge to improve access and searchability.
This also allowed us to consolidate disjointed experiences and provide a consistent look and feel for all these services. Finally, it was a chance to revisit some existing processes that were not working effectively for us, like our product enhancement requests.
Once we had agreed on the various functions we expected our portal to host, it was time to select the right platforms. While there was no vendor covering 100% of our needs, we chose AnswerHub because it provided most of the components, including a searchable knowledge base, idea box, and integrations. We used a more specialized backend for our Quali University training platform.
For code repository, GitHub, already the ubiquitous standard with developers, was a no-brainer.
We also worked on making the community content easier to consume for the target developer audience. We included ShellFoundry, a command line utility that would make it simple to create new integrations.
With a few commands, this CLI can get developers started in a few minutes. Behind the scenes are TOSCA-based templates covering 90% of the developers’ needs. They can customize the rest to build the desired automation workflow.
You can check out the Quali community here.
Once we got all the pieces in place, we needed to grow the community beyond the early adopters. We started by educating our sales engineers and customer success managers about the new capabilities, then communicated it to our existing customer base.
Since searching and asking for technical information was so much faster, customers embraced the new experience. They can also see what we’re doing with the ideas they send to us. Our idea box lets community members endorse other customers’ suggestions to bump the priority of a given idea. We’ve had hundreds of ideas submitted so far, all nurtured diligently by our product team.
The first signs of success with our community integrations came when we got technology partners signed up to develop their own integration with our product, using our SDK and publishing these as publicly downloadable content. We now have 49 community plugins, and we’re still growing.
To motivate new participants, our platform offers a badge program that highlights the most active contributors in any given area. For example, you can get the “Bright Idea” badge if you submitted an idea that is voted up five times. We also created a Champion program to reward active participants in different categories (e.g. community builder, rocket scientist, etc.). We invite our customers to nominate their top contributors and once a quarter, we select and reward winners who are also featured in an article.
To build a thriving community, you need patience first and foremost. But it’s also important to outline your overall goals, define the scope of the project, research appropriate solutions to host the various aspects of the community. We worked hard to make this a one-stop shop for developers currently working with us and those looking to work with us in the future. The goal was to make sure the concept was neither too narrow nor too broad. Given the growth of our community, I think we hit that sweet spot.