Keynote: From Contributor to Co-founder: Building a career and company on open source

In 2004, as a mid level engineer, I walked in the door to a research lab at Syracuse University called the Center for Natural Lang. Processing, where I was asked to build an English-Arabic cross language search system My boss said. “We use Apache Lucene, go learn it”. Little did I know, my life was forever changed by those 7 words. Usage led to contributions. Contributions led to committership. My work on Lucene eventually transitioned to work on Solr [TRANSITION] ———- Originally started in 2007 as the “Red Hat for Search”, Lucidworks has evolved from its early days providing support for Apache Lucene and Solr to its current state selling products built on open source. In that time, we’ve seen a variety of community, industry and internal changes that have both helped and challenged us as a company. Lucidworks co-founder Grant Ingersoll will highlight the opportunities and obstacles we’ve faced as a company as well as his personal journey from contributor to co-founder and CTO of an open source company.
The CNet extension of Lucene they donated to the Apache Soft. Foundation, calling it Solr — Search on Lucene with Resin. People started emailing me out of the blue, “can you help me implement Lucene?” “Can you help me implement Solr?”
2007 — 3 committers on the project, plus a user formed Lucid Imagination, which became Lucidworks 2008 — raised $6M to be “Red Hat for Search” This talk, then is an abbreviated version of what I’ve learned about building and growing an open source company.
Open source is great for lots of things, like collaboration, distribution, finding like minded people, creating community It’s not, however, a business model. This is a bit of old news these days, despite some companies still trying to force it via convoluted licensing models Talk about our evolution to open core from support and consulting Open source is a lot of great things, it’s a license. It’s a way of distributing software. It’s a way of finding like minded individuals, much like you all. It’s a way of creating community. [ANIMATE] It is, by itself, not a way of making money. If you are going to run an open source based business, you need to find a model that works for you. Consulting is nice, but it isn’t going to get the return venture capitalists are looking for. We tried the support route, it failed. Many open source support-based models are built on the notion that the software is just good enough for people to get successful, but not good enough that they can do it alone. Unfortunately for us, Solr pretty much works. Our customers, in those early days, used to, in fact, give us the nicest cancellation letters. In order to survive, we had to find a different route. That meant building a commercial product on top of Solr. We chose the open core route. You may choose a different route.
Commercial product What to donate Data product, how can we store and process more Click algorithms Layers around or unrelated to core retrieval and storage are part of the core So, a commercial product it is. As soon as that decision is made, the next question to come up, from your employees, your customers and the community is “How do you decide what to donate to open source?" This one took us a while and we had a lot of engaging discussions, before ending up on our current approach. For us, since we build a data product, the answer that emerged (for the most part) came about by simply asking the question: does this help us store and process more data at the storage layer? Thus, most of our contributions are centered around making sure that we have a stable, scalable database (AKA Solr) Everything else that was about introspecting that data or combining that data could go into the pieces around the open core
Things going well, then… Hit by a train, a train called Elasticsearch Interesting that our biggest competition was from another open source project Hard questions. Doubled down on our open source commitment to address ease of use and scaling such that we are now on par At this point, things are going mostly well, and then we got hit by a train. A giant open source train called Elasticsearch. In fact, it’s rather interesting that our biggest competition at the time that emerged was not one of the bigger companies that we were disrupting coming after us, but in fact an upstart open source project that tapped into a an emerging trend in the development community. They forced us to ask some really hard questions of ourselves and the community. We figured out what devs liked about it and we set to work to mitigate the biggest differences between the two projects around scaling and ease of use. I won’t say we magically solved those issues, but we at least got back onto equal footing, such that these days, the two projects are pretty much on par feature wise, in my totally biased opinion.
Interestingly enough, the rise of Elastic may have, in fact, saved us, both by forcing us to answer those hard questions as a company and a community as well as showing a broader set of developers that search can solve a lot of really interesting challenges in the data space. It really, however, forced us to define who we wanted to be. It wasn’t good enough to be the “Red Hat for Search”. In case you’re wondering, if you’re ever describing your company or your project as the Red Hat for X, or the Uber of X, you’re doing it wrong. Elastic forced our hand. Sure, we doubled down on Solr, but we had to find something more.
— Adoption of yet another open source project is what allowed us to escape a number of these issues around contributions and competition — Made it easier to justify what we are charging for and has all but eliminated the “what differentiates you from the open source” view of the world — IOW, the whole is now greater than the sum of the parts That something more was yet another open source project, this time, one called Spark. Our real sweet spot came along as a product when we created a bigger picture by combining two open source projects along with a whole bunch of other stuff. We could safely box the donation question by the fact that set of features we shipped aren’t fully contained by either community and we unlocked another level of differentiation for Solr and Elastic. IOW, the whole was now greater than the sum of the parts. Turns out, people were willing to pay for it, too, because the things we made easy on top of those two pieces of open source are really hard and would take them a long time to replicate, while still giving our customers the ability to extend and enhance.
- find the symbiotic relationships between commercial and community my early idealism around open source, for better or worse, has turned into a pragmatic approach. This is something you see happen in most communities, in fact, at least the ones that survive. Every open source business needs to find it’s own balance of what to contribute and what to keep. Likewise, you as community members need to think deeply about how you build a sustainable community and it’s relationship to all members of the community
Thank you!

Keynote: From Contributor to Co-founder: Building a career and company on open source

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Mehr von All Things Open

Mehr von All Things Open (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Keynote: From Contributor to Co-founder: Building a career and company on open source

Hinweis der Redaktion