October 10, 2019
Collaborating with Developer Relations Part 2: Sales
Both DevRel and sales teams spend time with customers and prospects out in the field, which creates mutual understanding, but can also resul...
Just because you’ve built an amazing community, doesn’t mean you’ve built a viable business. How do you balance open source, community projects and self-serve users with the need to drive commercial revenue? This panel of C-level execs discusses the choices they’ve made to support developer community, encourage platform adoption and concurrently scale to the enterprise.
Erin McKean: Next to me we have Christina Noren, who is the CPO of CloudBees. All product management, all engineering, design, all docs and product marketing. That all rolls up to you, and you’ve been doing product for 25 years?
Christina Noren: I’ve been doing different things in software for 25 years, but product for more than half of it.
Erin: You’ve been at Splunk, and–?
Christina: Yes, I was the founding VP of Product at Splunk in 2005 and stayed past the IPO in 2012.
Erin: Matt Biilmann.
Mathias Biilmann: I’m Matt Biilmann, CEO and Co-Founder of Netlify. We are a platform that developers use to build and maintain modern web projects with.
Erin: I think most of y’all probably know Isaac Schlueter at npm, the founder and CPO. You’ve been working in open source for–?
Because you look remarkably young for how long you’ve been working in open source. Because open source ages you.
Erin: I’m Erin, as it says on the sign. I’m a Developer Relations Program Manager at Google, and I work on the open source strategy team. I also run Wordnik.com, the biggest dictionary nobody’s ever heard of, which is now a 501c3 nonprofit. When it was a venture backed startup we actually worked in open source, we released the API framework formerly known as Swagger, which is now open API. So there’s a lot to talk about with open source, and I think one of the first things that people talk about in this context in open source is “Why?” What are your free-tier, your open source software, your community endeavors? How do they contribute to your go-to market strategy? Is it worth it? What’s the ROI and how do they inform your commercial products? Why don’t we start with Christina.
Christina: For those of you who don’t know CloudBees, you probably know Jenkins. We’ve been the major corporate sponsor and employer of the Jenkins founders and most Jenkins core committers since 2010. The Jenkins adoption and that community has driven a base of enterprises that are trying to industrialize CI/CD. That’s been the base that we’ve been able to sell into, where we’ve got close to 50% of the Fortune 100 as paying customers when people are trying to scale their CI/CD from a single Jenkins server. So for CloudBees, open source has been a key part of the strategy. Our founders came out of Red Hat and JBoss.
It was almost a no-brainer that “If you’re going to do something that’s developer centered, you need an open source community as its base.”
I bring a little bit more of a freemium community model experience, so love me or hate me it was my decision in 2005 to make Splunk freemium but closed source proprietary and not open source. It was an open question when I got there. I think it was the right decision in 2005, I think there’s room for freemium to land and expand communities of developers that are extending and building on top of. Users of free products, they’re technical practitioners and open source communities, and at this stage of CloudBees we’re trying to get the two to coexist.
Erin: Matt, you have a classic model.
Matt: We have a classic developer bottom-up product that’s a platform as a service, but that’s surrounded by a lot of free open source efforts. Our core product is a fully managed platform running a CI/CD pipeline, our own application delivery network and a local development environment, tying all of that together. But then we’ve surrounded that with a lot of investment into the open source community, into projects like Hugo, Gatsby, Vue and React that also run all of their web properties on Netlify, and contributed properties like Netlify CMS, or our identities service as an open source product. We have a model more similar to GitHub, where you can say that our own core platform is not open source but we engage a lot with the open source communities and see ourselves as big supporters of it.
Erin: All y’alls models are a little bit different than what sometimes people really think of as the classic open core model, and sometimes you talk to people about open core and they start nodding their heads. Then when you really dig in you’re like, “Wait. You have maybe a slightly different conception of open core than I was working off of, or maybe you were working off of.” I’d love for y’all to talk about what you think that really means, and how viable do you think it is right now? Who’s doing it well, in your opinion? Matt, you look like you have ideas.
Matt: It’s a good question, “Who is doing it well?” Probably GitLab is doing a great job of this, and has reached a lot of people.
Erin: We’ve got GitLab stans in the audience.
Matt: I think it’s always been challenging for the ones that really start very strongly with an open source project to go from having to both build and maintain that open source project, it’s a ton of work to actually work with a community and accept pull requests and triage bugs, and make sure that contributions is something you actually want. Then at the same time you often also have to build a separate product that’s not the open source product, so they end up getting two different product streams that they have to work on with the same team as if they only had one. I think that’s the challenge that a lot of the projects that start purely open source has, where there is maybe an easier model.
In the case of Netlify, we’ve supported very strongly a lot of different open source projects, and we’ve made a platform that you can use with React, with Gatsby, with Hugo, with VUE and with anything that comes up in that space without us being one of the specific players in that space, and without us having to build our own framework on our own site generators or anything like that. That allows us to just focus on building our core platform, and then building open source projects more in the periphery of that and contributing back to the community, but not having to own it and be the open source project.
Erin: Now Christina, you actually do own an open source.
Christina: Sort of. We don’t legally own the project, in fact we just helped start with Google and others of the Continuous Delivery Foundation, and helped arrange the transfer of Jenkins and the new Jenkins X project to that foundation. I think we went through a stage that’s similar to what you’re describing, our adolescent stage, where we started making a significant amount of money from the enterprise flavor of Jenkins. We got a lovely, very strong enterprise sales team in place, and we started having arguments internally that spilled to the external community about, “If we’re going to develop this thing that is being asked for, if someone’s willing to pay for it, that an enterprise sales rep brings us, then we should make it premium.” That got us to the verge of something unhealthy, and I think we’ve pulled back from that and we’ve doubled down our commitment to the resources internally that are contributing to pure Jenkins open source.
We’ve tried to delineate a clear line, and really we don’t consider our commercial premium product to be a flavor of Jenkins anymore, and architecturally it’s evolving away from plugins to Jenkins to something that is more than CI/CD, that leverages Jenkins for the CI/CD execution. That lets us be cleaner, that has let us take some things that we had made proprietary and make them open source, and so for now we have a line. We also introduced CloudBees Jenkins Support and the CloudBees Jenkins Distribution, so we really are making that clear line of “If you need CI/CD for an individual development team, then we want to continue to invest in Jenkins being your best option for flexible self managed CI/CD. If we have gaps there, it’s a priority to fill them.” We want to make the free distribution stuff that is also developer adoption driven, but is maybe more than what people think of, and you’ll see that over time. But we’re very willing to have things hop over the line into open source when conditions warrant that. Then we’re building a lot more innovation in the line, for the premium product it’s really when you have many teams trying to coordinate software development across an organization.
We can monetize support off of an individual Jenkins server, so we’re trying to make a more clear delineation, and it’s something we have the luxury of doing at scale, so we just made an acquisition of Electric Cloud that was announced the week before last. At that stage that puts us over 500 people. We have enough commitment on the part of our leadership to really invest in product and in open source, so we have the luxury of doing that. But I think a clear delineation and really being forceful as a product team with your sales team in saying that you build products for market segments, and one existence proof of one customer, or even 10 customers, willing to pay you for something that should be on your open source line is not a reason to make it premium, and rob your open source project of success.
Erin: That segues nicely into managing your community and taking that community from open source to paid.
You don’t necessarily want to take everybody in your community to the paid product if open source is solving their pain point and if they might not be great customers long term.
I know npm is doing some really good marketing now to the community, I’ve gotten several quite well-worded emails from you in fact.
Isaac: I think I wrote some of them. Yeah, it is a fine line to walk. I’d be busy loafing around on a private island if everyone in our community was a paid customer. But like you said, it doesn’t make sense, and if the open source product can meet their needs then from my point of view that’s actually good.
The purpose of our paid products and the purpose of our enterprise motion is to really do business in such a way that the people who need the enterprise features are paying for them, and that payment is subsidizing the growth of this open source movement.
Erin: Matt, you also have “a magic button?”
Matt: We’ve always been looking for one. Since our model is really getting as many developers as possible on board with our platform and making Netlify part of the tool build of any web developer out there, and then selling over time to the companies that these developers work for and are employed by. We’ve always said internally that if we had some magic button we could press where, any developer using the product would not pay anything, and instead the companies that they work for would automatically pay us, that’s the button we want to press. Because developers are also horrible to monetize from, I always remember seeing some very technical co-founder of a company that had IPO’d talking on stage at a developer conference and opening a code editor, Sublime Text back in the day, and the little nagging window pops up saying “Can you please pay me $29 for a one time fee for the tool you use the most in your whole professional career?” He just instinctively pushes the cancel button, because “Of course not,” right? That’s how developers work, but on the other hand,
As soon as a company hires developers to build something for them, there’s typically a pretty big budget involved because developers are not cheap, so that’s where you want to charge for the value you’re providing.
We’ve always been looking for “Where is that magic button where we can make sure that when developers come in and kick the tires and build their own projects and participate in open source, they don’t have to pay. But once there’s a real commercial use case, that there is also a real business plan behind it.”
Christina: Can I argue with you just a little bit on that point? So, I don’t quite agree with the idea that just because a developer is working inside of a company that the tools should be paid for by the company. I don’t know if you meant it quite that literally.
Christina: First off, I think it’s most important for companies like ours where the adoption starts with practitioners and developers, to get that platform adoption, and that base line of adoption, and the adoption of people learning to code in school, learning on hobby projects, working on open source projects. Then within companies, working on experimental or innovation projects. These are all places that habits get formed, and I think that’s the part that’s really hard, because it’s so hard for an enterprise sales organization or marketing organization that comes from a company that is classic trials, marketing funnel, whatever, not to consider the entire community their marketing funnel. For me platform adoption is key and engagement is key, and learning and building that community is key.
That was very true for us with the free community of users at Splunk, we did decide to make it proprietary but we decided to do everything else as if we were an open source community, and be very transparent and open, very engaged with our users, very generous with our communications and with our support and everything. That was early days, things have changed a little bit and evolved, but we loved having a community of people who would show up to Friday night events who were kids in school playing with Splunk. Those were people who became the basis of professionals who brought Splunk from company to company with them. So, really try understand that’s a different thing, and as soon as they get a job with a company that company is not going to invest in their tools yet. It’s got to be a point at which the projects they’re working on, or things need to become an enterprise standard.
What we want them to do is we want them to do such cool stuff inside their companies that other people become aware, and they want to start making it a platform in their company.
Erin: When we talk about communities that we are reaching out to and trying to convert some, not all, to paid customers, community is not really a faucet that you can turn on and off. You have to keep maintaining, keep building, keep reaching out to your communities. But how do you balance the effort that it takes to maintain community trust with commercial success? If you spend all your time maintaining your community, that is not going to work well. If you spend all your time trying to sell them stuff, that’s not going to work well either.
Isaac: I think really this comes down to having really clear understanding and really clear definition about what you’re actually referring to when you say “Community,”and “Maintain,” and “Manage.” Because people throw around these words and frequently have very different understandings of what the word actually means, and “What is referred to by our community? What is referred to by what kind of management, or what kind of engagement are we talking about with them?” I’ve seen throughout my career countless times where two people have a meeting and frequently, in all honesty, sometimes I’m one of them. We have a meeting and we all agree and we all nod our heads and we all walk out, we even take notes and we all agree to what the notes say, and then we leave and we are thinking completely different things because we had never actually taken the time to drill down and say “What do we mean when we say community?” That’s really crucial.
They’re all part of our community but you can’t engage with them all in the same way, and using the same techniques. In some cases what it means is engagement with this or that open source foundation, or pulling some representatives or select members in to advisory boards, or to product management discussions, or just sending out mailing lists and being engaged on all of the social medias and in GitHub and all the different forms for those. We actually have a website called npm.community which is a discourse board, and that is also not the definition of what our community is. That’s just a part of it that are deciding to engage in a particular way, so I think it’s important to meet these people where they are and figure out what you mean by “Community” and how you want to grow it and why, and why strategically that’s valuable. Make sure that you’re really drilling into specifics when you’re talking about this with your team, because you can go off the rails real easily.
Erin: Matt, do you have some specifics about your community?
Matt: The idea of concentric circles resonates a lot, we always fought about that especially with developer products. You have these specific early adopters that you want to reach first, and then it flows out from there. My Co-Founder and I, we literally started with a list of 20 people that we had to get hold of, and at least half of them had to get what we are doing and think it was a good idea. Because we identified them as the ones that were already thinking in that space and had already built stuff in that space, and if they thought what we were doing didn’t have value and didn’t add something then we should probably go back to the drawing board and rethink things. We really started there, and then grew it from there. It’s a little similar to the notion of content marketing in general, where you have to give something that’s valuable to the community all the time.
When we push out something that’s open source it should be something that some people find interesting and valuable enough to build around it and adopt.
You have to constantly think in that way, “What is it that’s lacking out there?” Look at the existing community and see where there’s some gaps in content or in tooling, or in open source projects that if you can fill in people will get real value out of and get excited about.
Christina: If I may, for just a second. I think one thing that’s lurking behind both of your answers that I want to call out. I’d say it’s a Venn diagram of your open source community and your company community, and different roles. For your open source community, and I’m less the expert on this than our founder Sacha is, but there’s a whole set of techniques about getting contributors to your project and getting people to do stuff with you, and getting companies to do that with you and getting developers to do that with you. That is a really important part of the machine, and then there’s the level of if you have extension points on either your open source or your free product, getting an app developer community and an ecosystem around your product or your project is a whole different thing. Then getting community dynamics around the users of your project or product is a whole different thing, and these are going to be overlapping sets of people and companies, and I think that it takes different people in the organization to be attuned to each of those different subsets of the community and spend their days really focused on that.
Erin: That’s a good point. Also, when you were talking about ecosystem building, having third party developers plugging into your open source product or your commercial product, that sounds like a community-driven thing that actually leads to revenue.
Christina: It leads to revenue directly from those developers less than it does from all the people who want to use what those developers have built. The plugin ecosystem around Jenkins is an example of that, the app ecosystem around Splunk is an example of that. It just makes everything larger, and people and individuals float between these different roles and they also permeate as you grow. People leave the community and come and join your company, and then go back out, and then come back out, and go here and go there. Individuals take their habits with them. We’ve been having this conversation a lot at CloudBees, because there’s a little bit of disbelief in terms of hardcore open source folks that you can have a developer ecosystem around a free but premium or a commercial product just based on APIs and extension points. I think Splunk, Slack– There’s a ton of existence proofs against that. But it does allow developers to make a proprietary tool their own, which gets to a level of love in the community, which is something we haven’t been talking about here. Which is, “How do people start loving being part of this community and ecosystem, and building relationships with each other, and emotional relationships with working on this product or project?”
Erin: We see that with closed source API products like Stripe and Twilio, there’s a lot of love for those and they’re not open source.
Erin: Are there other community behaviors or community activities that in your experience have led directly to product revenue? Matt is shaking his head.
Matt: I’m just thinking.
Erin: He’s like, “All those site generators.”
Matt: Obviously, we’ve invested a lot on our end in growing the community around tooling. We’ve even now seen companies like Gatsby that when we started out, were small hobby projects running on our platform that’s now become venture-backed companies, and projects like Storybook that has risen up, and so on. They are all in a space where we’ve helped seed the ground, and helped them even with contributions and with sponsorship, and so on. They are now a core part of our funnel as well, in that we have lots of enterprises buying the package of sometimes Gatsby, Netlify and Strapi, or something like that. That’s all come out of that open source community that didn’t even really exist back when we started.
Erin: Anything you want to add, Isaac?
Isaac: The main ways that we’ve seen revenue come about from our open source users is, as team sizes grow the needs of that team start to grow, and if the three of us wanted to build an app and use npm, we wouldn’t really need anywhere special to put our proprietary code, our closed source code for our app. We’d just put it in the Git repo, and when we push a new change we just tap the person on the shoulder and say, “There’s a new change. You need to pull it before you build.” Once you grow to about five people, that starts to become really onerous. The lines of communication start to multiply, or it’s a factorial relationship, and so what we’ve seen is a few natural tipping points as team sizes grow where our Org product starts to make a lot of sense. When they start to grow beyond that, an enterprise product starts to make sense. Because now at an enterprise scale you have collections of teams, you have multiple different teams that all need to leverage one another’s code, very similar to the way it works in the open source ecosystem itself. As a company grows it approaches the biggest enterprise, which is open source.
Christina: I think actually, if you’re looking for something more tactical, because my first reaction and my open mouth reaction to the question is “That’s not a question to me,” which is “If you have a strong selling proposition and go-to market for your enterprise or commercial product, anything you do to build the base of users on the contingent open source or free product, of course it helps. Anything you do to build development ecosystem around that to make the product better, of course it helps. Is it cost effective? You have to run the numbers, but it’s a no-brainer.” But then I was thinking about it more, and I think we may be looking for something more tactical. So, events. “How do you get anonymous open source users who are very familiar with, or free users who are very rabid users, that you don’t know are using free Splunk, or open source Jenkins, and how do you address them in a way that doesn’t put them off?”
Events at both Splunk and at CloudBees have been key to this, webinars are increasingly important, you create content that appeals to the average open source or free user, that is not hard sell, and you have elements usually of users or sponsors of the commercial use of product of your customers also at those events. I like to run panels that mix free and open source and premium users, and when I run those panels I like to have challenging questions. I like people to say all the reasons that open source or free is fine, and I pushback on the hard sell, because it’s about getting the community to sell each other. It’s much better for an open source Jenkins developer at our customer ABN AMRO to get on stage at one of our events and talk about the distinct value of using the commercial CloudBees product and us not to do the hard sell.
You can advertise these things to the community in various public forums and so forth, but you have to be genuine about advertising them as community events and you just happen to be present there with your commercial product.
Erin: Definitely events. Get the word out in a non-salesy way, if you do them the right way.
Erin: We have time for one more question, which I really wanted to give you all a chance to say “OK, we all have had a lot of experience, all as founders as well.” What would you tell a founder who’s starting today about free-tier, open source, open core, community-driven efforts? If you were the ancient mariner, what would you grab them by their arm and say “You have to listen to me about this.”
Christina: You can’t do community or open source as an afterthought. Like, “We’re going to open source this thing that’s been commercial and mildy successful, but not successful enough,” doesn’t work. You have to design it from the first, and the decision about free versus open source or doing both, to me, is driven by, if the primary engine of selection of technology is going to be developers self-selecting that technology, it has to be open source today. You can do other premium stuff, but the foundation has to be open source. If the engine is that they’re just selecting a tool or a service in the market, you can do freemium, but you have to do either open source or freemium if you’re going to be practitioner-led. Then you think about land and expand and the cutting off point for commercial, but you can’t work backwards from an enterprise model that’s middling working and work your way backwards to a practitioner-driven model very effectively.
Matt: Be mindful of which one you pick. Don’t just pick one because you like open source, or something. Pick one because it’s right for the product you’re building. Think about, “Is this a product that has a path where people can very easily adopt it and go onboard, or is it a product that requires that someone comes and really gives a sales pitch and an introduction and a demo?” There are very quick products that just inherently work, or that doesn’t have a simple free onboarding flow that makes any sense. So build it into the product from the ground up and think about it as if you’re building this kind of product and that you’re really building in the acquisition and sales channel into the product instead of having it as an external part. That has to really make sense for the product before you start doing it.
Erin: There’s a lot of nodding going on from you, Isaac.
Isaac: Yeah. Everything they said was great. Trying to think, if I could go back in time and grab myself by the shoulders, what I would say? I think that open source is not a verb, don’t use it as one. If it’s not already open source you’re not going to get much value by open sourcing it. Just go do a different thing. I would say whenever possible, open source the tools and freemium the services. Just as a simple rule of thumb, you don’t need the service that you’re providing via a web endpoint or whatever, to be open source, because people are just going to hit it anyway. The fact that they can get the source code is not really that big of a deal.
But if you want tools to be picked up by practitioners, that tool has to be open source, because that’s going to be your entry point, and people will tend to use a free open source tool even if it’s significantly worse than a paid proprietary tool. A lot of people will use the open source ones just because they know they can fix problems with it, or they can get help from a community. I think the third thing is to build a community by focusing on the ways that people are going to use your tool to meet their own needs. “How do people using this tool make money? How can people using this tool attain fame and notoriety in an open source community? How is it going to help them get a job? How is it going to help them have satisfaction in their life?” Whatever the need is that your tool is meeting, that’s going to be the thing that gets them to adopt your product and gets them to become evangelists for your product.
Erin: Thank you all for sharing your often hard-won experience and knowledge with us today, and I think that’s all the time that we have. Thank you so much.