These are the lessons I learned turning an open-source database project into an enterprise software product and the pitfalls I fell into.

In early 2015, my company Aurelius got acquired by DataStax to turn the open-source graph database Titan into an enterprise product offering. We had several enterprise customers who had adopted Titan and were asking for enterprise features and 24/7 support. By joining DataStax - a much larger database company with a globe-spanning support team, a sales team, and experience in the enterprise software space - we were hoping to meet our customer demand more quickly than building out these functions ourselves.

I wrote in detail about the lessons learned during the acquisition in a separate post. Here, I want to focus on the lessons I learned turning an open-source database project into an enterprise software product [2].

Enterprise Software Product - A Definition

What does “enterprise software product” really mean?

Let’s start with the easy part: software. A collection of code that people find valuable. That was our starting point. At Aurelius, we developed the open-source graph database Titan and people found it useful to store and query their graph-structured data.

“Product” means that you can package, advertise, sell, deliver, and service the software in a way that makes money. We had done a little bit of that at Aurelius - my cofounder was good at content marketing - but mostly we relied on the open-source community to drive our consulting business.

The “enterprise” part is a bit of a catchall that refers to features, functionality, and services that enterprises need but other users can do without. Examples include 24/7 support, operational tooling to simplify management, advanced security features, compliance features, and integrations with other systems that enterprises often use (like LDAP). Many users of Titan were running the database by themselves. They figured out how to setup monitoring, configure authentication, and would dive into the code to determine how to make Titan work for their use case. We would be regularly amazed by what folks were doing with Titan. For example, one JVM tuning wizard at a hedge fund managed to squeeze phenomenal performance out of the system. But most enterprises aren’t interested in such “hands-on” adoption of software. They will happily trade money for features that they commonly need to run the software within their larger organization successfully and without too much work. Those features are referred to as “enterprise” features.

Don’t Lose Sight of the User

Developing an open-source database system, it was pretty easy to be in touch with users and understand what we needed to do to make the software better. We had an active mailing list, a public issue tracker, and users would reach out to us on social media. I took the closeness to the users of our software for granted. It made it easy to plan our roadmap and prioritize features. Moreover, there was a pretty straight forward feedback loop: if users felt strongly enough about a feature and pay us to implement it, it would get done first.

As we transitioned to building enterprise features, we started to get more into our heads about what exactly we should be building. Partly, we thought that it was “obvious” that we needed certain features and functionality to be “enterprise-grade”. Like, audit logging for graph queries. At the time, it was hard to see that we made a bunch of assumptions about what was critically important for enterprise customers and what could wait for later releases. In other words, instead of focusing on what the MVP was for an enterprise graph database, we ended up in an echo chamber of “this list of features is obviously needed for an enterprise database”. Not being in constant contact with the users we were building for allowed us to maintain this echo chamber.

On the other hand, it is a lot harder to be in touch with enterprise users. People who play around with and contribute to open source projects are often willing to provide feedback, share how they are using your software, and what could make it better. And, by definition, they are willing to play around with software even if it isn’t fully baked yet.

Enterprise users of database systems are a lot harder to find and talk to. And when you talk to them, you think you are getting honest feedback but you are getting socially acceptable niceties. It is notoriously hard to get good user feedback and entire books have been written about the subject. I learned the hard way that getting valuable feedback from enterprise database users is even harder. They are busy, they are dealing with a lot of internal bureaucracy, and they have learned to interact with enterprise software sales teams.

At the time, I was utterly unprepared to cut through all these layers of obfuscation. I’m still not very good at it. The key is to identify champions for your software inside enterprises and build relationships with them over time. This requires a lot of effort and nurturing.

The most useful feedback is from a user who is trying out your software. Getting enterprise users to invest time into using software that isn’t released yet is extra challenging. In the OSS world, there are plenty of users who will try a 0.1-alpha because they are curious. It’s a lot harder to find those users for enterprise software. You have to invest a lot of energy and resources to provide value to those users and maybe - very maybe - they will give it a shot. Over the years we tried beta programs with “direct access” incentives, hackathons with prizes, or pair-programming engagements to get enterprise user feedback.

None of those is a silver bullet. I’m becoming increasingly convinced that there isn’t one. Just be prepared to spend more time and effort on this than you’d like. Feedback is critically important to ensure that you are building the right product. That is equally true for enterprise software products. And enterprise users have special pains and needs that you need to elicit through active feedback channels.

Beware of the Water-Scrum-Fall

Enterprise software is an interesting beast because you are under opposing pressures to release rarely but make sure that your software is as up-to-date as possible.

There is a pressure to release rarely because your customers are typically not thrilled to upgrade your software [1]. This is especially true for databases that are critical to applications because upgrades in those environments require careful planning. But on the other hand, your customers want the most up-to-date version of your software and all the latest and greatest features.

In practice, this leads to an overstuffing of releases. In particular for major releases of new software. So, we were adding too many features and also over-engineered those features because there is this sense that “it needs to be perfect”. Who knows when we get to do another major release again? Better get it all in there before the door closes on us!

We spend a lot of time planning out all the features we needed to deliver for v1 of our enterprise graph database. And we added even more planning because we wanted to make sure that those features are engineered in the best way possible to deliver high performance, high predictability, high observability, and make it easy on our support team. These are all important non-functional requirements but combined with the uncertainty surrounding the features and a sense of finality this led to a lot of over-thinking and over-engineering.

Because we were still doing 2-week sprints and followed the SCRUM methodology it felt like we were doing agile. Of course, we were missing an important ingredient: actual user feedback. But since that is hard to get feedback on pre-release software, it’s easy to disregard that omission as a minor process deviation. After all, we were going through all of the SCRUM motions and it felt very SCRUMy.

The fact, however, is that we were doing the water-scrum-fall. We were doing a waterfall engineering process while pretending to be agile.

I’m not trying to get into a debate about software engineering processes. Smarter people than me have thought and written about this at great length. What I learned is that developing software for long periods without actual user feedback leads to hallucinations. You start to hallucinate critical features. You create a whole alternate reality on how important tail latencies are for particular query workloads or what a user expects from query tracing.

And when you finally release your software, that alternate reality collides with the actual reality and the result is often very shocking. I was shockingly wrong on some of my most beloved assumptions.

Whatever software engineering process you prefer, make sure that it keeps your hallucinations at a minimum by forcing you to interact with the reality that’s out there. It will be worth it.

Engineering isn’t Everything

When we embarked on this journey to build an enterprise-grade graph database, we started with a long list of features that we needed to implement. I assumed that my highest priority was engineering management and internal product manager. That I needed to focus my energy on giving the engineering team all the structure, guidance, and product details they needed to work through that feature list successfully.

What I ended up ignoring was the “product” side of “enterprise software product”. What are the primary value propositions that this product is delivering and how do we communicate those? How do we price the product? What does the support team need to adequately support the product? What materials and training does the sales team need to be able to sell the product? And how do we sell the product to our sales team?

In other words, I blissfully ignored support enablement, product marketing, sales enablement, and finance. It was only weeks before the release date that I realized what was missing. Once I realized, it was a mad rush to try to fill all those holes. And in this mad rush, I produced some sloppy work that needed to be reworked later.

All in all, it took another four months after the official release of DataStax Graph before we were able to sell the product effectively. That’s a lot of wasted time which could have been avoided had I realized the importance of non-engineering tasks to building a successful product.

Engineering is critically important. Without the finished software, there is no product. But coming from an engineering background and having worked on OSS software before, I had a blind spot for all the other aspects that make a successful software product.

Summary

I learned a lot during our journey of building an enterprise graph database product and hope that these lessons allow you to avoid some of the mistakes I made along the way.

I am incredibly proud of the team for building and shipping a distributed graph database product despite these struggles. DataStax Graph is now used by many enterprises across the world. Bryn Cooke, Dan LaRocque, Stephen Mallette, Jonathan Lacefield, Daniel Kuppitz, and Marko Rodriguez: thank you for all your hard work in making this happen.

I also want to thank Sven Delmas and Martin van Ryswyk for their relentless engineering support. And a big thanks to Robin Schumacher whose patience I stretched thin with my lack of product experience.

Footnotes

[1]

This comment applies in the context of on-premises software. Luckily, this is not a concern for cloud-delivered software.

[2]

The opinions expressed in this post are my own and do not reflect those of my current or former employers.

[3]

Photos by Markus Spiske, Krissana Renae, and Katarzyna Gonsior on Unsplash