Design considerations for open-core software

See more posts about: Product

For over a decade, software has been in the cloud and we’ve been carrying tiny computers in our back pockets. This means software costs less, but our expectations are higher, and we have witnessed a major uptick in both consumer demand and market supply for digital experiences. If software is truly “eating the world” then our approach to design matters a lot.

We take a different approach to designing enterprise versus consumer software, and we also think differently about designing for commercial versus open-core.

Understand the journeys

All software design begins with understanding: What problems are you trying to solve, and are you solving them in a compelling way? How do people find your software, and are you making it easy to figure out whether it makes sense for their organization? Does your software respect and support the complexity of customer needs?

Commercial software designers focus on product buyers and product users. What sets open-core software apart is that developers are a key audience. At Puppet, external developers contribute to our open-source projects and also to the Puppet Forge, our online community that hosts code modules which extend the power of our products.

A simple example of an open-core software conversion journey; your mileage may vary

The particular needs of developers introduce additional considerations to the design process: How do developers influence a software purchase? How do they contribute to our code base as beginners, and how can we help them become experts? What prevents them from contributing, and how can we mitigate those issues?

Once you get an understanding of how individual developers relate to your product, you can begin to consider them as a group.

Nurture the community

It is a mistake to believe that all of your open-source users are somewhere on the path to becoming commercial customers. Address and support your open-source community for its own sake, not as a bucket of potential future conversions. This means identifying ways to make it easier for them to connect to you as well as to each other.

For example: Puppet Forge currently contains more than 6,000 modules, and only 1% of them were written by Puppet employees. That means hundreds of community members are writing and sharing thousands of modules that help others do more with Puppet products. It’s impossible to calculate the exact value of that labor, but it’s definitely very high.

In return we maintain the Forge, host the Puppet Community on Slack, and hold Contributor Summits and Puppet Camps around the world. We also invite the community to give us their input and feedback on product design through our Puppet Test Pilots program.

Help developers help you

We also provide tools and support that help developers do this work more easily. A few years ago, we surveyed Puppet developers to find out if and how they were testing their module code. We learned that they were using more than 40 different test tools, and that they were overwhelmingly dissatisfied with their current methods. Some of them wanted us to write a test tool, but most simply wanted us to suggest or prescribe the best way to test.

Some example survey responses

We looked at the module creation workflows in place (there were many) to identify the biggest pain points, and created a Puppet Development Kit (PDK) with functionality and support for:

  • Deciding which skeleton to use when they started coding a module
  • Building a suitable test environment
  • Testing and validating the completed module code

So far, so good... But our work doesn’t stop here. It’s also critical to be as transparent as possible about your roadmap. Developers need to know where your platform is going so they can adequately prepare for changes that may affect their own business and product strategies. A developer-friendly roadmap should include changes to terms of service, backwards incompatibilities, and new features from which app users could benefit.

Finally, developers should be included in a platform’s long-term strategy when possible. Be open about current known issues and downtimes. Most developers understand if the communication is open.


Our company thrives because of our strong community. To all of our community members: Thank you for all that you bring to Puppet. We appreciate you.

Melissa Casburn is a senior principal user experience designer at Puppet.

Learn more

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.