Early in 2014, we launched our company Tesora as the OpenStack Trove company focused on the open source database-as-a-service project. This wasn’t, however, a brand new open source company. We began our life as ParElastic, developing a proprietary engine that could transparently scale-out MySQL.
This transformation has been an exhilarating process that can be characterized by the ancient Chinese blessing/curse: “may you live in interesting times." We’re now the number one contributor to a fast growing community open source project and have fully embraced an open source strategy. I thought our experiences going through this transition would be interesting for others considering a shift to an open source business model.
The ParElastic days
As ParElastic, we developed some powerful technology and were headed down the traditional path of supplying proprietary software to enterprises. Our vision was that databases would one day be consumed like a utility—in a pay-for-use model—that is not limited by the performance of any single database server. We did this by allowing them to scale out across services and by supporting multi-tenancy, making this scalable capacity easily shared by many users. Our work was new and innovative, as evidenced by the 10 patents we were awarded, but we ultimately struggled to gain meaningful market traction.
Something we heard frequently from prospective customers was that they strongly preferred open-source solutions, or even that they would ONLY use open source software for infrastructure. At the same time, we were offering a very targeted solution for a select set of customers who were committed to relational databases, needed to scale-out and didn’t want to (or couldn’t) implement sharding themselves. Given typical open source conversion rates, it was difficult to see how we could build an open source business on such a targeted technology since most great open source companies are based on building a platform.
The shift to OpenStack and Trove
In response to these challenges, we started exploring ways to fulfill our on-demand database vision while embracing open source. owards the end of 2013, we began looking at OpenStack Trove, the open source Database as a Service project and it looked like it could be a very good fit. We joined the OpenStack community and as we began to contribute became even more excited about the possibilities. In fact, in February 2014 we re-focused our business strategy on Trove and even changed our company name to Tesora to signify this strategic shift.
There were a couple of things that made our move to open source a bit unusual. First, we weren’t the original creators of Trove as is typical of companies that are the leading contributors to an open source project. (Trove was originally developed by Rackspace and HP to power their public cloud DBaaS offerings at scale.)
What we found in joining the community, however, was that we were welcomed with open arms. While I’m sure part of this was just the “open source way,” I think the other contributors to the project also recognized the benefit of having a company focused on productizing the great work that they were doing.
They also saw that we brought a different skill set to the project. As a team with deep expertise in database internals which was built to deliver packaged software, we could package a hardened product that other enterprises could adopt without the level of investment that the founders of the project had to put in.
Second, we didn’t have a lot of “open source DNA” in the company. Frankly, we had very limited open source credentials when we changed direction as Matt Asay pointed out in ReadWrite and other people, rightfully, questioned our ability to make the transition. We had a lot to prove.
Next steps to the open model
It was hard for the people in the company to get their heads around this shift in the business model. How do you make money with open source? Isn’t open source free? We discussed how we would do this, though in the end, it will really be a matter of proving it as our company grows.
Our processes needed to change as well. Our team had not been building software in an open source community before. They needed to understand and learn the protocols of participating and collaborating by IRC and adopt all the other development tools that are standard issue in the open source world.
Another difference was that when it comes to open source projects, not everybody is in the same geography. While our team was already geographically distributed (we have offices in Boston and Toronto), our participation in the Trove project took this to a new level.
Another big change was that we could no longer make all the decisions! Rather, in the open source community, we could contribute to and influence decisions, but couldn’t “just decide”. We also needed to demonstrate we could contribute to move the project along in order to have our voices heard.
We changed the culture of our development team to embrace open source while keeping in place our people and their expertise. To accomplish that, we had help from other people in OpenStack and Trove, plus people from the open source community around Boston. For example, Tim Callaghan, whose company Tokutek had gone through this transition a year before, provided lots of great advice based on his experiences.
Another great resource as we went through our pivot was our board of directors who were very supportive and helped us navigate this transition. For example, our lead investors, General Catalyst changed their board representative to Donald Fischer, who had worked at Red Hat and had a tremendous amount of open source DNA. Fortunately, our investors shared our vision of transforming IT through database as a service, so while it was a radical shift in our go-to-market strategy, our vision remained consistent.
Balancing community and company objectives
Over this past year, we have also learned that we must balance the needs of the community with those of our business and our customers. We know we can’t convince the community to do everything we want to do to meet our customers’ needs. The needs of the enterprise are not always aligned with the needs of the open source community. We therefore must innovate outside the community in some cases. There are also times when we need to deliver capabilities more quickly than the community can accommodate. In those cases, we sometimes develop features on our own and then contribute them back when the community is ready to accept them.
Another thing that we’ve learned is that our enterprise customers want to be certain that the databases they plan to use will work on their preferred OpenStack distribution. To accommodate this, we test many different configurations with different databases and distributions. This kind of certification is something that the community considers to be outside their purview.
So, the nuance here is understanding the difference between the motivations of the community and project versus delivering a product that is easy to install and deploy by enterprises. That is the value that companies like Tesora can provide beyond the project.
We made the right decision
Looking back, where are we today nearly one year later?
The OpenStack Trove project is healthy and we’ve become the leading contributor. We’re working alongside lots of other companies and people contributing time and talent to Trove to make it successful. We’re delivering a product based on that project that makes it easy for enterprises to deliver on-demand database capacity to their users.
With the benefit of hindsight, looking over this past year and our baptism by fire into the world of open source, I’m glad we did it and can honestly say that there is no place I’d rather be. We’ve made many good friends working alongside others who are part of OpenStack Trove and I truly believe the future is looking brighter and brighter for our company, Trove and the OpenStack project as a whole.
1 Comment