As of today, Bitlancer has decided to open source our Bitlancer Strings “Puppet-as-a-Service” configuration management software offering and focus primarily on consulting services. The code is now available on Github.

When we started selling Strings over four years ago, it seemed to make a lot of sense given the pressure we felt in the marketplace. We were doing basically the same type of consulting work for almost every client-and Strings seemed like a win-win proposition: why not buy a tool instead of paying us to build one for you?

But four years is a long time in our industry and we’ve learned a lot. Here’s what drove our choice to open source Strings:

  • Is Bitlancer a product company or a services company? Trying to be both has probably hurt our business more than it’s helped. We need to focus.
  • We tried to make Strings a minimum viable product (MVP) because we felt most solutions out there were overcomplicated graphically. Everybody seemed to love our control panel approach to using Strings-but anybody who wanted to adopt it also wanted an API for automation. We didn’t have a good answer to that, because we built so much logic into our control panel.
  • We had no experience with pricing and were always struggling with how to value Strings. When prospects would ask us what it cost, we’d hesitate. And that undermined confidence in the product.
  • As a very small company, our product was somewhat of a liability even though it looked great technically. Would we be around to support it? As standards evolved, popular tools like Chef gained traction and cloud service providers started offering their own toolsets. AWS expanded their native tools and services at a time when we didn’t even have AWS support. Betting on Strings made less and less sense for most.
  • Strings’ architecture is monolithic, not modular. If you want to use one part, you have to use all of it. Many organizations liked aspects of Strings very much, but balked at using it whole-hog.
  • We didn’t offer support for AWS until it was too late. Nor did we focus quickly enough on supporting smaller cloud service providers. Mostly, we built on OpenStack and aligned ourselves with Rackspace, and as they’ve added more and more tools and services to their platform(s), our ability to provide addded value in a product has faltered.

In hindsight, we probably should have initially offered Strings as open source, perhaps creating a premium edition when and if significant traction developed. We also should have remained simple from the beginning (minimum, minimum viable product, anyone?) and made it less OpenStack-specific. We really would have loved to focus on supporting Strings rather than selling it, because that’s what we’re good at.

Could we keep Strings alive, fix it, and get people to buy it? We have little doubt-the product is definitely useful to the right folks-but as a services company, that doesn’t sit well with us. Strings is a less-than-optimal solution for most businesses at this point, and we’ve lost our passion for it. There are some awesome tools out there that are better aligned with the goals of today’s organizations (such as the ability to actually write code against an API), have communities behind them, are more mature than Strings, and ultimately will offer lower cost and risk to our clients.

And, yes, we want to support our clients as they continue to implement what’s best for their business and team(s). That’s the best use of Bitlancer’s skill sets and the best way for us to further our mission. Just don’t be surprised if some of those solutions contain stripped-down bits of Strings! :) And remember, the tools you choose are only one part of the DevOps puzzle. Don’t forget about everything else!

Meanwhile, if you’re interested in taking a look at the Strings code or seeing what part(s) of it might be useful for you, check us out on Github. The Strings Documentation may be a particularly decent starting point. If you like it, please use it and keep us posted on the results.