These two things are linked in one question: what are we going to charge for?<\/p>\n
Support Staff, Support Poaching<\/h2>\n
\n The first question is, really, the same question any company faces, closed or open source. The answer is tried-and-true: assuming you’re providing an increasingly amount<\/i> of support to your customers, you have to hire more people or write better code. We like to think that open source produces high quality software that doesn’t need a lot of support, or that “the community” will off-load a large amount of support. Either of those could be true on a case-by-case basis. But there are two problems:<\/p>\n Assuming support is actually needed<\/i>, signs point to the need to beef up support staffs at open source companies, which is fine. The only difference between open and closed source in this context is that open source companies will need to charge more for support since there’s (ostensibly) not an up-front license fee as closed source companies have.<\/p>\n As mentioned above, there’s also the chance that the software’s community can take care of support. Usually the assumption here is that that community is made up of the collection of people, archived email lists, and other “self-service” support that end-users will access or engage with. That is, instead of relying on a central core to draw support from, end-users will just use Google, IRC, or other channels to get, more or less, “free” support.<\/p>\n As a customers, if this option works in a timely fashion, it’s great: you don’t have to pay anyone. As the open source vendor, you don’t want the community to take care of every support case: otherwise, you have nothing to sell. Now, following the rising tide lifts all boats theory, the open source vendor only needs to get paid for a minority part of the over-all support provided to “the market”\/community, but they need to collect money for providing some<\/i> of that support.<\/p>\n Overall, going off my gut and past experience in closed source, enterprise software, I feel like there’s plenty of money and desire for support. Much to the dismay of 3rd level support staff on 6 hour long support calls, businesses always want to customize the crap out of their software. They rarely want to go down the cheap path, instead choosing to spend time and money crafting the software to fit their needs rather than waddle the business around the software. This is fine: the consequence is often that software rarely works “out of the box” and that the cheap answers to problems are often overlooked in favor of the highly customized and “cheap” option. It’s a dream for support-based revenue!<\/p>\n Here, we’re trailing into the subtleties of IT Doesn’t Matter<\/i>:<\/p>\n To simplify it, if IT Doesn’t Matter<\/i> it true, then support sales should decline significantly. Sort of paradoxically, if IT ever “just works” it’ll cease to “matter”…to open source vendors, at least, who’re looking for support sales.<\/p>\n This sort of tension is older than dirt: if I give you something that works perfectly and does everything you want for free, what else is there for me to charge you for? Why buy the cow when the milk’s free, as they say? Let’s move on.<\/p>\n You’ve got to have enough people who’ll trade money for their own time.<\/p>\n An interesting, and highly contemporary wrinkle in all this is what several people and I talked about at length: the Unbreakable Linux move. The problem here is: if your revenue is based off support, what happens when someone else is successful<\/i> at “winning” (or “stealing” if you prefer) support contracts from you? RedHat and Oracle are examples, but Spring and numerous other companies are an up-and-coming example as well.<\/p>\n I always think of this as the software equivalent of dumping<\/a>.<\/p>\n Getting specific for a moment, it was interesting at OSBC to hear how many people thought of RedHat as the sort of market success key-stone for open source businesses, if not the software industry in general. If RedHat tanked, the thought would go, we’d all suffer, because:<\/p>\n I’m not positive I fully buy into the gloom and doom there. But, I do certainly believe that something different<\/i> would happen should RedHat tank. Same as with Google or any other “yet to fall” high-flyer, of course.<\/p>\n Generalizing, the question in the case of support poaching becomes: what company is best suited to provide the best support? (The assumption is that buyers will tend to buy from those best suited.)<\/p>\n At the moment, the prime metric for figuring out how “good” any entity will be at supporting a given piece of open source software is how many commiters or “core members” that entity has on the project. This matters because when fixing bugs or introducing new features, you want the fix rolled back into the mainline of the project, not just “patched” for your instance. You want to avoid forks and duct-tape.<\/p>\n Put another way, as Steve and I discussed with EnterpriseDB’s Andy Astor awhile ago<\/a>, a large part of providing support for an open source project is being an advocate for your customers in the community. While it’s certainly possible to be an advocate without being a core part of that community, being part of the project certainly gives the support provider the highest chance to get what the customer wants. (That’s not a locked in chance, just a higher<\/i> chance.)<\/p>\n So, controlling the community as much as possible is the best path for companies wanting to make money (beyond consulting) off providing support for any given open source project. Though it seems like a pretty safe bet, this isn’t a sure path for safety: if rainbow-and-sandals ethics evade large company execs, I think we’ll still see smaller open source companies porked by larger ones who can effectively spend-seige those smaller companies into a starvation. That is, “dumping.”<\/p>\n Of course, the closed source world is littered with stories of companies who either didn’t take out young up-and-comers while they could or otherwise let those threats whiz by and blossom into peers.<\/p>\n Another look-back to draw from: does Microsoft make the most money in the market of Windows support, or are there better and richer people who provide Windows support?<\/p>\n \n I’m quite sure Eben Moglen’s keynote about lunch eating<\/a> touched on some of the poaching points above. Indeed, in the numerous conversations I had about support poaching, MySQL was regarded as essentially immune from poachery because their dual GPL licensing, control of all<\/i> the IP, and project commiters gives MySQL exclusive control over the code-base. This model goes by the name of “single-entity open source” meaning that a single entity (here, the MySQL company) controls and “owns” the source and, thus, the heart of the project and community.<\/p>\n The alternative to this setup is a “multi-entity” in which any number of different entities work on and “own” the source and operate in the community. Apache projects are (or can be) multi-entity, Linux is multi-entity, Spring is (right?), and so forth. I hope to see OpenJDK go multi-entity as soon as possible: the interim governance board is a hopeful start<\/a>. (Though, it’s worth pointing out McGovern’s comment<\/a> that there are no enterprise reps on the interim board.)<\/p>\n One is often drawn to give any open source operative a rating of “how open source” they are. I get the feel that this single- vs. multi-entity discussion is partly a run to make another measuring stick for that favorite parlor game (which, you’ll recall, I find boring<\/a>).<\/p>\n More tactically, the single- vs. multi-entity discussion is instructive for the open source business model you’re drawing around an open source project. I don’t have it figured out, but at the moment it seems that maintaining MySQL like control over the project is the easiest way to provide profit runway.<\/p>\n To throw out a theory<\/i>, successful open source business models need to either:<\/p>\n One point that I haven’t brought up and that wasn’t covered too in-depth at OSBC (from the participation I had, at least) was the role that traditional brand-tacticts could (maybe) play in open source businesses<\/a>. The word “brand” has a bad wrap for software people as it connotes the sort of snake-oil huckstery that we think only “users” would succumb to, not us smart-y coders. That is, it feels like the words “lie” and “deception.” Pulling that crud off, some contemporary brand-think strikes an almost 1:1 mapping with what we’d call “community management” in the open source world: establishing co-creating relationships with your customers. To put it in base terms, it’s the difference between being comfortable vs uncomfortable with the word “consumer.”<\/p>\n Ultimately, all tooth-paste is pretty much the same, but we tooth brushers have our tooth-paste crushes and hates. Open source operates this way in many cases, but I’m not sure the methods of establishing consumer-BFF have been implemented on a wide-scale in open source businesses. Some interesting brands to think of here: GNU, Ubuntu, Firefox, and Spring. In each of those cases, and others, in addition<\/i> to the technology itself, the ideas and culture of those brands motivate people (consumers, users, customers…however you like<\/i> saying it) to frequent the respective products. Of course, Google is a great example: is it really so much better than other options that I use it all the time, without thinking? (James<\/a> could expound on how Google’s success as a brand has fogged up people’s thinking of Google as a privacy threat.<\/p>\n I mention brand because it connects back to my main conclusion from OSBC: really, the business<\/i> of open source software is panning out to be pretty much the same as closed source software. Sure, the legal mumbo-jumbo is different, and we call people “community managers” instead of “product managers,” but you’re sort of doing the same things when it comes to innovating, taking care of your ecosystem, and then charging for something<\/i>, probably support and services. Thus, when it comes to branding and marketing open source, I often feel like it’ll be the same old story: be nice, responsive, and be sure to show up. A lucky rabbit foot seems to help too.<\/p>\n One thing I didn’t explicitly touch on is the question of what success is. Clearly, if you’re an investor in an open source business, success is making as much money as possible: success is getting the company acquired for millions or IPO’ing. Success is not just plodding along, paying the bills, with slow but steady, perhaps platauing revenue.<\/p>\n In the case of investors, the trick is figuring out how make money off the weird ways open source is successful. Think of Eclipse or Firefox. I don’t think a traditional way of investing would work there. On the other hand, IBM and many others who “invest” in Eclipse clearly benefit from Eclipse. Firefox actually makes good money<\/a>, but how does “an investor” do something with that?<\/p>\n There are three views to take on this:<\/p>\n I feel like most high-flying open source businesses (like Interface21) fall solidly under the first category. On the second point, it’ll be interesting to watch MySQL<\/a> and VMWare<\/a> as each goes public and figures out what that means in the near future. The point is that we have an open and closed source vendor, each at the Morlock<\/a> layer of IT. On the third point: well, that’s just the plain old risk of doin’ bid’ness, right?<\/p>\n I mean, is it just me, or is it feeling like open source businesses are pretty much like closed source ones? (Which would be a mostly good<\/i> thing, mind you!)<\/p>\n Disclaimer:<\/b> MySQL<\/a> and EnterpriseDB<\/a> is a client.<\/p>\n <\/p>\n Technorati Tags: gnu<\/a>, support<\/a>, osbc<\/a>, osbc07<\/a>, brand<\/a>, oracle<\/a>, redhat<\/a>, linux<\/a><\/p>\n <\/p>\n","protected":false},"excerpt":{"rendered":" The state of open source businesses, as informed by my experience at OSBC ’07.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11,12,17,19],"tags":[],"class_list":["post-807","post","type-post","status-publish","format-standard","hentry","category-conferences","category-enterprise-software","category-marketing","category-open-source"],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts\/807","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/comments?post=807"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/posts\/807\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/media?parent=807"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/categories?post=807"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/cote\/wp-json\/wp\/v2\/tags?post=807"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n![\"spend](\"http:\/\/farm1.static.flickr.com\/219\/511037058_1d0169f09f.jpg?v=0\")
<\/a><\/p>\n\n
\n
Support Poaching<\/h3>\n
RedHat as the Cash Key-stone<\/h4>\n
\n
Evaluating Who to Buy Support From<\/h4>\n<\/p>\n
History<\/h3>\n
The MySQL, Single-entity Gambit<\/h2>\n
![\"Eben](\"http:\/\/farm1.static.flickr.com\/197\/511449500_1ea2bb125f.jpg\")
<\/a><\/p>\nSomething to Charge For<\/h2>\n
\n
Branding<\/h2>\n
Exits: What is Success?<\/h2>\n
\n