Not to knock developers, but writing code is much less stressful than handling support. There are pressures to be sure, but the number of unknown variables to be managed in a coding project is less than those in the average support issue. I constantly face support issues that could be due to configuration issues, the customer’s network, the server, the operating system, or bugs. Last week alone I dealt with one client who was having issues because they used Solaris tar versus GNU tar on a build (Solaris tar tends to truncate long file names) and another client who had bad memory in the server (which resulted in a number of crazy symptoms). Those aren’t easy to catch.
Add to that the fact that you are interacting directly with the client, and there is a lot of pressure to perform.
Following up on my post from yesterday, here’s a brain-dump of sorts of the types of support open source companies could and do provide. “Support” is always, for me, an overly general term and I’m rarely satisfied to let pass a mention of “selling support” without trying to dig for details. That is, what type of support are you providing? How much are you providing?
Here, I’m narrowly interested in support on it’s own. There are many other things an open source company can sell (networked services chief among them, as well as the “cash box of open source” that management companies like Hyperic like to talk about), but I’ve felt like there hasn’t been a detailed look at the support aspect.
Open Source Support: is there enough demand?
I’m always skeptical of open source companies replicating closed source revenue based solely on of “support.” Note that just because I’m skeptical doesn’t mean it turns out all the time that I was right to be skeptical. As Steve pointed out last week in the context of non-support revenue models for open source companies:
Much of the revenue directed open source firms way thus far has been related to their willingness to pick up the phone when things go awry. In that respect, it’s remarkably like insurance. And though insurance is a fine, profitable business to be in, it’s not likely to be quite as rewarding or profitable in the software business as it is elsewhere. Nor are the ISVs needs aligned particularly well with the customer. If the ISV does a perfect job with the software, after all, why would the customer pay for support?
And there’s the sort of bill-paying programmer’s dilemma: if you write quality code, open source it, what are you going to get money for?
In truth, there’s always the need for support in software. Software is a very imperfect thing, and the “bigger” it gets, the more “real” bugs and the more “bugs of use” (configuration, using it incorrectly, or the desire for new features) you’ll get.
Programmers, End-users: Middle-ware vs. Applications
The first crooked part in my thinking about open source support comes from the fallacy of combining programmers using software with end-users using software. In general, I’ve found that ISV programmers (people who write applications [packaged or SaaS delivered] to sell to other companies, not “corporate developers” who write in-house applications) are less prone to use support for software, closed or open source. The mentality, to my mind, is that figuring out the problems you might use support for is a large part of what the programmers do.
For example, in a recent Java Posse episode, Dick Wall commented that he used to use decompilers to hunt down bugs in third party applications to code around them. That is, rather than “passing the buck” to the third party software owners, programmers often just take on the pain themselves and “figure it out. This is the kind of mentality I encounter among programmers quite a lot: it’s insulting to them to suggest that they need help.
If I had only that scenario in my head, then, open source support would seem tragically doomed. That’s not to say that there aren’t revenue opportunities in supporting developers using open source, just that code-monkey culture is a hard stone to squeeze cash out of.
On the other hand, once you get those cheap programmers out of the way, support opportunities seem to abound: people who actually deploy, run, and maintain the software are ready to point the finger away from themselves (to whoever they’re paying for support) much more rapidly, and rightly so.
So we’ve come to a couple of important customer distinctions when providing support:
- Developers – support for developers using your software to build their own software to sell. This camp usually falls into the camp of wanting to trade time for money, spending time to “figure it out” themselves rather than seek 3rd party help.
- Runners – support for “the IT department” who’s given the task of running the software. This camp usually falls into the camp of wanting to trade money for time, using 3rd party support rather than figuring out themselves.
To be honest, I’m not quite sure where/how to generalize what I call “enterprise developers”: those writing software for their company to use. I would assume they’d use more support than the Developers, but that could just be my own Developer arrogance biasing me (us Developers think we’re the top of the heap!). I’d appreciate any input.
Also, there are a few distinctions to make about the type of software being supported:
- Middle-ware and OSes – something that doesn’t have a UI or much end-user exposure, the lower levels.
- Applications – the layer of software that people actually interact with, typically though a UI.
Of course, one person’s lower level is another person’s upper level, and so forth…
Types of Support
Yesterday, I listed the types of support I recall providing in my closed source life: bugs, scaling, configuring, upgrades, finger pointing (or proving who’s “right”: the software or the user), re-setting expectations (the software actually won’t scramble an egg inside it’s shell like the sales guy said), and your million dollar nightmare (customizing and supporting out-of-date deployments).
Obviously, the same types of support exist in the open source world. What are some types of support more unique to open source support?
Updates
The first, and most common type of “support” open source companies provide is simply getting access to updates to the software. Indeed, RedHat makes it’s money from tightly controlling this aspect of their Linux distribution. There always seemed to be something a little un-open about that model to me, but, hey, you gotta make money somehow, right?
The things worth paying for here are:
- Getting the updates quickly.
- Getting the updates seamlessly
- Trusting the updates.
What seems “weird” to me, then, is that these are things I’d expect the open source projects should do themselves. More importantly, if an “owner” of a project sets themselves up as basing their revenue model on updates, there’ll be a strong inclination, conscious or unconscious, to always make updates “something worth paying for” in the sense that they’ll never be speedy, easy, and trustworthy from “the community.” And then there’s that whole Unbreakable Linux cultural-quagmire. Of course, you should be wary of anytime I use “should”: it usually means I’m thinking idealistically instead of pragmatically (apply circular-irony to this sentence as well ;>).
However, what does seem interesting in the update stream support offering is providing updates for old, “unsupported” versions of the software. That is, there will be customers who want to run old, old versions of the software that no one wants to maintain and apply patches to. In software, any time there’s software developers avoiding doing something there’s a revenue opportunity. If the developers don’t want to support and patch version 3 of some software that’s at version 10, there’s (hard) cash on the table for those who’ll brave going back in time to version 3.
In general, the more undesirable it is to support, the more cash there is to do it.
Support usually includes “professional services”
Mark Hinkle of Zenoss noted in a follow-up post that in providing open source support he’s seen less need for install/upgrade support and more need for customization support. I more-or-less left out the case of “customization” from yesterday’s support list because in the closed source world, customizing the software is usually separated out from “support” unless you, the customer, wants to become a million dollar nightmare.
Indeed, in larger companies, there’s whole other departments called things like “professional services” or just “services” to help custom fit the software to your need, even coding up layers for integration and so forth. In the enterprise software shops I know, this function is usually branched off to be part of the sales organization, which always seemed weird. You don’t hear about open source “professional services” too much, I reckon, because that notion is folded into the notion of “support” at open source companies. And as some related background: as Steve noted last year, you’d think systems integrators would be all over open source for improved margins.
Stacks: I promise this will work
Another “support” business model for open source companies is to certify that a stack or piece of software works. This is sort of confidence arbitrage in that the certifier is more confident that the software will actually work than the customer and, thus, can charge for that difference in confidence.
This isn’t just all hand-waving, of course: stack companies like SourceLabs, SpikeSource, and others are trusted to actually test the software and even certify different standards (security, for example) to the stacks. Stack companies rarely, if ever, just provide stack certification, also providing a stream of updates and traditional support as mentioned elsewhere here and in yesterday’s support.
Better out of the box install, integration, and use
Providing better, more user friendly install, integration, and overall experience is another popular revenue stream for open source companies. This isn’t exactly “support,” but it definitely impacts support when it comes to integration and install, so it’s worth mentioning in this context.
Be for-warned, this path is usually the one where you get bogged down into arguments about who can call themselves an open source company. These companies usually have a layer of closed source code used for the “betterments” and because it’s closed source, more open sourcey thinkers will throw mud their way. As the mud-slingers would put it, there’s huge difference between just using open source and being an open source company.
RedMonk clients like GroundWork and EnterpriseDB fall into this category. Steve and I spoke at length with EnterpriseDB’s CEO, Andy Astor, about this sometime ago, so I won’t hammer it too much.
Scaling and Optimizing
While scaling and optimizing the software falls under the “business as usual” category (you do this in closed source support) it’s worth calling out because of how frequently open source companies mention it to me. Scaling software (making it handle 1,000’s and 100,000’s of operations, data points, etc. at a time) is always a challenge for any type of software.
Optimizing in this case is sort of the pre-deploy face of scaling. That is, figuring out how to best use a piece of open source software ahead of time. Here, I’ve spoken with many open source companies who provide pre-deployment support as far as best practices and “patterns” for using the software. Inherent here is the pooling of knowledge in the open source company: they’re the experts on using this software, so you should pay them to help you.
This is more of a consultant role, but again, that concept seems to have gotten rolled up into the concept of “support” for many open source companies.
Being an Advocate to The Community
One type of “support” that I haven’t heard too much about from open source companies is being an advocate in the open source project’s community for the customer. We talked about this in the interview with Andy Astor, and it seems like a natural, if difficult to sort out type of support to provide.
While we’d like all users of open source software to participate in the community, not all users may want to. Indeed, they might rather spend money than time to be “involved.” The support then would be taking the concerns of this sub-set of customers to the community when it comes to the direction and over-all “management” of the community.
The sticky part here is working out conflicts of interest or simply conflicting interests. To use two derogatory terms from US politics, a company offering advocacy here is setting themselves up to be called “lobbyists” for “special interests.” I’m not really sure if that characterization is justified across the board, but it’s definitely a trap to look out for.
As an example, take open sourced Java, and throw in the JCP. While everyone who uses Java doesn’t have the time to get involved in the nose-to-grindstone development of Java or the standards process at the JCP, they might like more explicit ways to paying other people to be involved on their behalf. We’re always aching for “enterprise users” to get more “involved” in open source, and maybe this is one way to actually do it.
Others?
I’m still curious if there are other types of “open source support” you, dear readers, have given or gotten. So, please leave a comment below if you can think of something I’ve left out.
Plenty of Opportunity
Taking a deeper look at what type of support is and could be provided for open source software, it’s clear that there’s plenty of need-cum-money on the table. Software is always breaking and not working as you’d expect it to, esp. as you move up the stack from OSes, to middle-ware, to end-user facing applications. Even with just traditional support as outlined in yesterday’s post, there’s plenty need to have someone a phone-call or email away. I still remain skeptical of a high volume of developer support, but when it comes to support for running and maintaining the software, I’m more rosey.
Sometime soon I’ll write-up some notes on the challenges of providing support at open source companies: chief among them being the developer cultural stigma against being a “support person” that Tarus recently wrote-up. Indeed, for a developer, doing support is like exercising: it sucks, but it’s one of the best ways to improve the quality of your software.
Disclaimer: GroundWork, EnterpriseDB, Zenoss, Sun, and SourceLabs are clients.
Technorati Tags: support, consulting, optimizing, redhat, sourcelabs, groundwork, enterprisedb, spikesource, stacks, developers
Recent Comments