RailsConf 2019

The Unreasonable Struggle of Commercializing Open Source

The Unreasonable Struggle of Commercializing Open Source

by Justin Collins

In the presentation titled "The Unreasonable Struggle of Commercializing Open Source," Justin Collins discusses the complexities and challenges of transitioning open source software (OSS) to a commercial product. He begins by reflecting on his own experience founding and developing Brakeman, a static analysis security tool for Ruby on Rails, which he open-sourced during his internship at AT&T Interactive. Collins shares insights on the awkward dynamics between maintaining the original open-source project and offering a paid version, especially regarding naming conventions that can lead to confusion among users.

Key points discussed throughout the video include:

  • Naming Challenges: Collins experienced difficulties in creating distinct names for the open-source and commercial products, leading to brand confusion.
  • Competing with Free Versions: He emphasizes the challenge of persuading users to pay for a Pro version of a tool that is available for free; users see less value when they are satisfied with the existing OSS version.
  • Initial Pricing Mistakes: His team initially mispriced the product and had to adjust their pricing model significantly to attract paying users. Collins explains that pricing must reflect the market demand and customer willingness to pay.
  • Community Marketing Concerns: Collins discusses his discomfort in promoting the commercial product to the open-source community, which resulted in a decline in engagement over time.
  • Managing Open Source and Proprietary Development: He reflects on the complexities of maintaining both free and paid versions, including what features to allocate to each.
  • Moral and Legal Concerns: There are ethical considerations regarding the ownership of code contributed by others and the implications of GPL dependencies in commercial projects.

Collins concludes with broader observations about the sustainability and future direction of open source, referencing ongoing debates about licensing and the economic landscape surrounding it. He invites the audience to consider the evolving story of OSS and how it continues to contribute to and shape modern software development in light of these commercial pressures.

Taking away from the talk, Collins emphasizes the need for thoughtful strategies when commercializing OSS, balancing community expectations with business realities, and addressing the challenges posed by open-source licensing changes as companies navigate these waters.

00:00:20.630 All right, so this is a very large room, and for those watching the video, I want you to know it is completely full. Everyone here will back me up on that, as you can hear.
00:00:28.800 You may be wondering why there’s a picture of Hawaii on this title slide. It’s because I like to show people my vacation pictures. You know, it’s the way people used to force their neighbors and friends to watch slideshows at their house. So thanks for participating!
00:00:36.180 My name is Justin Collins. On the internet, you can find me under 'president beef.' I generally look like this or that online. A fun thing about Gravatar: once you pick a picture, it’s you for life.
00:00:46.290 I work at a company called Synopsys. Among other things, we have products to help you write better, safer code - static analysis tools, dependency analysis tools, and security consulting, among other things. I’d be happy to talk about that afterward if you like.
00:01:01.290 I just want to get this out of the way right up front: this is an awkward talk for me. It’s weird for me because it’s not a technical talk, and it’s also weird for me because I’m talking about myself. I usually don’t like talking about myself on stage!
00:01:14.340 So, I just wanted to get that out of the way. Also, I used a lot of drop shadows in this presentation, just preparing you for that and apologizing a little bit. Here’s some drop shadows.
00:01:24.869 This talk is split into three different parts: I’m going to talk a little bit about my experience, some challenges I experienced during that journey, and then we’ll talk about some ideas related to open source.
00:01:30.599 Let’s start off with my experience. This is what I looked like in 2010. I’m the one on the right.
00:01:36.119 In 2010, I did not know it, but I was at the midpoint of my PhD career, and my advisor was kind of running out of money. So, I had to find a job.
00:01:50.170 I found a summer internship at a company called AT&T Interactive. You may recall this company; they used to sponsor a lot of Ruby events, which is why I applied there.
00:01:55.679 Also, this was the place where Aaron Patterson and Ryan Davis used to work. I did not talk to them at all because I was way too shy to approach them.
00:02:06.030 When I got the internship at AT&T Interactive, I was placed on the security team, which basically kicked off my career in security.
00:02:16.260 While I was there, I created a tool called Brakeman, a static analysis security tool for Ruby on Rails. I hope by this point most people are aware and are using it.
00:02:27.139 But if not, that’s okay! This is how you use it: you install it, run it, and you’ll get a report about potential vulnerabilities in your application.
00:02:38.010 I created this as part of my internship project and then suggested, 'Hey, I want to open source this!' The response was positive, so I thought it would be great.
00:02:49.469 I remember asking, 'What license do you want me to use?' They said we usually use MIT. I remember that conversation very clearly; it was casual.
00:02:55.320 I found my original tweet about it; you can tell it's old because the link is not linked to a domain, and it also uses a link shortener. This was actually a few weeks after Brakeman was released.
00:03:05.400 The link goes to my blog on this wonderful website that I used to have with a bunch of drop shadows, and there's a line in there saying, 'Unfortunately, it's not yet compatible with Rails 3.0.' This is because Rails 3.0 was released a week after the first version of Brakeman.
00:03:16.660 Let’s jump forward now: I had an inkling that this was near the end of my PhD. I ran into a gentleman named Jim Manico at a conference, and he said, 'Hey Justin, if you ever think about turning Brakeman into a commercial product or building a company around it, let me know. I’d like to help.'
00:03:33.480 I followed up with him later, and I asked, 'Were you serious about that? Do you really want to help me do this?' He said, 'Yeah, let’s do it! But you should really bring in Neil.' Neil is the gentleman on the right. I thought bringing him in was a great idea.
00:03:44.670 Neil was the number-two committer to Brakeman and also my co-worker. So I said, 'Yes, let’s bring Neil in; that makes a lot of sense!' Now, you might notice that this picture is in Hawaii and looks kind of recent.
00:04:02.880 That’s because we took this picture a couple of weeks ago at a conference in Hawaii. I said, 'Look, we have to get a picture of the three of us together since we have no pictures of the three of us, the founders of the company.'
00:04:18.100 So, that’s why it looks recent, and it was in Hawaii! We ended up starting Brakeman Pro kind of in the vein of Sidekiq Pro or other companies that just throw 'Pro' at the end of the name.
00:04:29.480 Not a lot of thought went into the name, honestly. About a year and a half later, we put out the first version of Brakeman Pro. What was Brakeman Pro?
00:04:37.480 I get this question a lot, which means I really failed as a businessperson. We built a desktop application, kind of a front-end for Brakeman.
00:04:49.490 This was built on JRuby and JRubyFX, and we bundled it up with Java. People really liked the interface put together by our UX designer, Adam Corman.
00:04:59.920 That was one piece; it was completely separate from Brakeman, which was the open source project. Then we also had the 'Pro' version of the gem, which we called the engine.
00:05:06.960 It was basically like the open source one; you could even type 'brakeman,' and it would run Brakeman Pro. Kind of the same thing.
00:05:14.920 Then we had this third component, which was the Code Climate Pro engine, which allowed you to run Brakeman Pro on Code Climate.
00:05:26.940 You might have noticed we did not build a SaaS product or service around Brakeman itself.
00:05:34.360 One reason for this: Code Climate existed as well as several other providers I call 'Brakeman as a service,' and it didn’t make sense to redo the work they had done.
00:05:41.240 I wanted to focus on actually making Brakeman better instead of building a whole SaaS around it.
00:05:48.410 We started the company and basically saw very slow but steady customer growth; there was a little jump in the middle.
00:06:01.440 I believe that bump was due to RailsConf 2017, which gave us a bit of a boost. We continued this upward trend.
00:06:09.640 Last year, in 2018, Brakeman and Brakeman Pro were acquired by a company called Synopsys, which I mentioned earlier and is where I now work.
00:06:16.480 So, that was a very compressed eight years of Brakeman and Brakeman Pro, and it sets up the context of where I'm coming from.
00:06:29.679 Now, let's talk about some challenges. I tried to focus on the challenges that arise from taking something that's open source and trying to build a company around it.
00:06:40.339 These are also personal challenges, so I don’t want to misrepresent the experiences of the others in the company.
00:06:47.639 The first challenge is naming things; naming things is hard, and I think I did a pretty spectacular job there.
00:06:53.480 There was the thing called Brakeman, which was the open-source project, then we called the company 'Brakeman Inc.' The umbrella thing was Brakeman Pro.
00:07:05.170 Then we had Brakeman Pro Desktop and Brakeman Pro Engine, but I could never figure out what to call Brakeman Pro Code Climate Engine because Code Climate also calls their things engines.
00:07:18.909 We ended up with two things called 'engine,' which was a bit confusing.
00:07:27.360 I got called out on this; I posted a blog about some difficulties around commercializing open source, and someone said that using the same brand name for a revenue product and an open-source project was problematic.
00:07:34.360 She said, 'Fundamentally irreconcilable names equal different value propositions.' You can’t have two different value propositions with the same name.
00:07:46.460 To drive this home, I pulled up these tweets a couple days ago; this tweet is pinned on her profile, and every now and then someone will come by and like it.
00:07:54.510 It reminds me that I got called out even though we sold the company.
00:08:01.240 Next, naming things becomes a challenge when you have something that’s open source, and you want people to start paying for something related to it.
00:08:09.919 Now you’re competing not only with a free version but with your own free version that you are still maintaining.
00:08:15.919 I heard this a few times: 'Hey, the free version of Brakeman is great; we don’t really need Pro.' That was a compliment but also a hindrance.
00:08:23.310 It was hard to argue against their point.
00:08:30.620 Another thing that happened was I completely flubbed the initial pricing.
00:08:39.460 Initially, we were going to charge $2,500 a year for individuals to use the Pro version, and if you wanted the desktop app, it was another $2,500.
00:08:49.480 We thought of Brakeman as a security tool, and pricing it as such made sense, but our initial audience was mostly developers, like the folks at RailsConf.
00:09:00.020 Asking someone to go from paying nothing for this tool to $2,500 a year didn’t get us anywhere. I totally understand that.
00:09:07.780 In a situation where you're competing with something free, justifying going from $0 to a price point can be tricky.
00:09:16.100 We eventually revised the pricing, with the lowest price being $500 a year for individuals with the desktop app.
00:09:27.020 We also offered $1,000 a year for a site license, but that wasn’t an awesome business decision.
00:09:36.130 We also later added monthly pricing and adjusted these prices upwards a little bit. However, you still had to justify the need for a fee when there’s a free version.
00:09:45.710 Another challenge I faced was marketing to the community. This was a personal challenge for me.
00:09:52.650 I had this weird feeling of not wanting to push people to pay for something when they were happily using the open source version.
00:10:01.290 I once wrote an email when Brakeman had a mailing list, saying, 'We’re going to do Brakeman Pro, but don’t worry about it.'
00:10:07.800 I said, 'This will be the only email I send about Brakeman Pro to this list.' At the time, I felt very strongly about that.
00:10:14.110 I stuck to that promise, of course, while the mailing list eventually died.
00:10:22.130 Let’s get into something a bit more technical: managing open source and proprietary development.
00:10:31.640 You might think it looks like this: you have the open-source version, and then you fork it, and that’s it. But my experience has been a bit more complex.
00:10:41.020 Stuff goes from open source into the paid version. Sometimes, working on something leads to the realization that this feature needs to go into the open-source version.
00:10:51.290 Tip: if you have a closed proprietary branch, do not merge things from that branch into your free branch and bring all of your Git history along.
00:10:58.490 The good side of this challenge led me to mostly focus on putting things into the open-source version while maintaining cleaner separation with the paid features.
00:11:10.290 You may wonder then: what goes into the paid version and what goes into the open-source version?
00:11:17.460 A lot of people worry when a project does a commercial fork: 'Oh, you're going to abandon the open source,' and I didn’t want people to feel that way.
00:11:26.020 So, I kind of came up with a system, which is a bit specific to me but could help you think about it if you're considering this road.
00:11:35.200 I think there are three properties of the open-source version of Brakeman that are important: 1) it’s fast, 2) it has relatively low false positives, and 3) it’s developer-focused.
00:11:43.100 Then I thought, okay, the proprietary version can be slower; it can produce a wider array of results, and be more security-person focused than developer-focused.
00:11:51.460 This helped make some decisions about which features go where, for example, no one's really too worried about PDF or Excel reports being in the open-source version.
00:12:00.650 People don’t really ask for that, but if you're a security professional, you might want to.
00:12:09.930 Furthermore, Brakeman is not just some open-source project; it’s a security tool.
00:12:17.980 Now you have to wonder: if I do not include this feature in the open-source version, am I somehow affecting the security of Rails applications?
00:12:24.450 This is something I wrestled with. If I don’t put this in the open source, am I causing people to be less secure?
00:12:30.880 Though compromises were made, I tried to err on the side of including everything valuable in the open source.
00:12:37.490 Real quick comment: every time someone does a commercial fork, someone says, 'What if someone opens a pull request that implements proprietary features?'
00:12:44.440 In my experience, I have never seen someone spend that time to implement a proprietary feature and then try to submit it back as open-source.
00:12:50.960 It doesn’t seem like something that happens; you can address it on a one-off basis.
00:12:58.020 This was also kind of a personal problem with all the tasks I had to do for a Brakeman Pro and open-source release, which I almost always did at the same time.
00:13:06.540 By 'one-day work,' I mean starting at 9 or 10 in the morning and finishing at midnight or 1 in the morning.
00:13:13.690 This may not apply to every commercialized open source project, but this was a problem I faced.
00:13:21.000 Another problem I encountered was that sales are hard. I heard people say, 'Hey, that sounds awesome; I want to buy Brakeman Pro!'
00:13:29.020 But a lot of those people never bought it, and I’m not blaming them because developers don’t really buy software.
00:13:39.560 If you want to buy software at a company or spend money on something, you’re probably not authorized to do so.
00:13:45.840 You have to ask your manager; they have to review the budget, go through procurement, and justify it as a business expense.
00:13:52.870 So, someone at RailsConf telling me they’d buy it masks the reality of how things work in a company.
00:14:00.569 Another reality is that companies do not buy software to be nice.
00:14:06.729 They’re not going to say, 'Oh, I can pay you for something I’m using for free; I’ll do that because I’m nice!' I can’t look into their hearts.
00:14:12.800 But from feedback, I’d say that less than five companies purchased Brakeman Pro out of goodwill.
00:14:19.280 Let’s address some legal and moral questions. Who owns the code in an open-source project?
00:14:30.250 My understanding of U.S. copyright law is that it’s whoever wrote the code, and possibly their employers.
00:14:36.330 If I’m going to sell their code, is that okay? Is it okay for me to take someone else’s work and charge money for it?
00:14:42.690 This is a question you have to answer if you’re going to take something that's open source and try to make a business out of it.
00:14:49.040 Unless you have zero contributors, which is pretty rare, legal questions come up.
00:14:54.520 Another issue that came up was regarding GPL dependencies, which I had never worried about until now.
00:15:02.550 In Brakeman's case, there were like one or two GPL dependencies, and they weren’t critical, so we ended up removing them.
00:15:09.350 If you want to take a picture of the challenges I just mentioned, here’s a summary.
00:15:15.670 Let’s talk about open source: why do we feel the way we do?
00:15:24.290 I think it’s a lot like the keynote yesterday: what are the stories we’ve been told about open source?
00:15:32.210 This narrative has been shaped by the two gentlemen: Richard Stallman and Eric S. Raymond.
00:15:38.820 Stallman founded the Free Software Foundation, and Eric S. Raymond was involved in the Open Source Initiative.
00:15:47.140 These foundations set the foundation for how we understand open source today.
00:15:53.180 Recently, there have been articles like one from February that reads, 'The Internet was built on the free labor of open-source developers; is that sustainable?'
00:15:59.770 The phrasing suggests that it might not be. Building an Internet seems like a big task, and free labor doesn't seem sustainable.
00:16:08.540 DHH had thoughts on this, and if you want to pause and watch that, go ahead.
00:16:14.930 Per a report released by Synopsys a few days ago, 60% of commercial code consists of open-source components.
00:16:21.840 This data is based on our dependency analysis tool.
00:16:27.290 In the report, they suggest that this might be a low estimate, with some estimates going as high as 90%.
00:16:31.960 So 60% to 90% of the code companies are using to run their businesses is coming from open source.
00:16:39.650 The likelihood that they’re paying for it or contributing back is low.
00:16:45.050 An article that came out last week discussed Amazon's transition from a neutral platform to a competitor.
00:16:52.800 The title of the URL mentioned open source betrayal in reference to industry leaders blaming Amazon for competing unfairly.
00:16:59.440 I encourage you to read that article if you have time.
00:17:06.400 AWS has been in the news, having recently published a piece about keeping open source open.
00:17:12.540 They aimed to provide a pure open source distribution for Elasticsearch, as it had begun mixing up open source and proprietary code.
00:17:20.220 MongoDB also changed its licensing strategy, leading Amazon to introduce a MongoDB-compatible document DB.
00:17:26.000 The license change from MongoDB was not well received in the community.
00:17:32.309 Redis Labs also faced scrutiny for changing their open-source licensing strategy.
00:17:39.740 When these kinds of changes happen, people often comment that altering the license makes something non-open source.
00:17:47.660 This stems from the definition by the Open Source Initiative, stating that no restrictions can be imposed on the use of the software.
00:17:56.550 If you impose restrictions, it’s not open source anymore.
00:18:03.030 We have this idea of open source undergoing challenges when companies are trying to redefine their open-source involvement.
00:18:09.970 Steve Cloud wrote two articles, one titled 'What Comes After Open Source.'
00:18:16.680 In one quote, he mentions that today's developers may not care about the history of open source.
00:18:24.630 Something significant is happening, and those developers will define the future of what comes after open source.
00:18:33.580 Is it time for a new license, or maybe a new concept altogether? The world we live in today is much different from the world of 1985.
00:18:42.000 This matters because GPL licenses are based on the premise that if you build a derivative work based on GPL, distributing it means you also distribute your changes.
00:18:49.770 GPLv3 clarified that distribution means conveyed, which adds another layer of complexity when considering commercial projects.
00:18:57.540 The idea of derivative work is often interpreted as meaning modified software, and if you don’t modify, you have no obligations.
00:19:04.870 Let me tell you a story about a project called WPScan. It’s a WordPress security scanner.
00:19:12.540 Using GPL licensing, the maintainers went after companies building tools based on WPScan.
00:19:19.870 This led to controversy; one company posted a blog calling it 'robbed at gunpoint' after they were confronted by the maintainers.
00:19:28.080 This company ultimately decided to fork WPScan and create an open-source version.
00:19:38.020 The same situation arose with tools like Nmap, which clarified their licensing.
00:19:43.970 They stated that derivative work includes running Nmap, modifying its output, and presenting it to clients.
00:19:51.860 This interpretation has proven successful for them; they sell commercial licenses without significant issues.
00:19:59.340 There's another license I want to mention: the Brakeman Public Use License.
00:20:05.240 As part of the acquisition by Synopsys, Brakeman's licensing changed for various reasons, similar to other projects.
00:20:12.180 For most of you, if you’re using it for your own purposes, you’re fine to continue as before.
00:20:20.300 I’m happy to discuss this license with anyone interested afterward.
00:20:27.420 I want to pose a question: why is Creative Commons' non-commercial licensing unacceptable in the software community?
00:20:34.450 People seem entirely fine with non-commercial licensing in regards to Creative Commons.
00:20:43.090 However, as soon as you apply it to software, it becomes contentious.
00:20:50.390 I don’t know why this is a problem, and we should consider it.
00:20:58.180 To wrap up, I didn’t present any solutions. Many people have tried that already, but none have succeeded yet.
00:21:04.510 I want to emphasize how we think about open source and why we feel that way.
00:21:11.290 Why does the community react so strongly to certain changes? If you look at recent changes, for example, Chef switched to open sourcing more of their software.
00:21:18.830 You would think that the community would be supportive, but that’s not how it played out.
00:21:27.560 Unfortunately, I don’t have grand conclusions, but I hope I’ve provoked some thoughts.
00:21:35.570 There’s a Birds of a Feather session happening right after this in Zone B.
00:21:41.890 If you're interested in discussing this topic more, feel free to join!
00:21:49.230 I appreciate you all for attending and you can find me on the internet as president beef.
00:21:54.080 I will post these slides online. All the slides and talks I’ve ever done are on my website.
00:22:01.940 If you have any questions about Brakeman, feel free to ask me.