SpringSource on a slippery slope

This just in, thanks Bertrand:

Rod Johnson: “Anyone who refuses to compile an open source project under any circumstances doesn’t really believe in open source: they believe in other people working for them for free.”

I couldn’t agree more, but that’s not the heart of the problem. I actually happened to agree with Mark Brewer when he was explaining me the new SpringSource policy in Paris, yet I’m afraid they completely lost me if it’s true – as Steve notes – that they are keeping SCM build tags secret. What’s the next step? Taking the build files away? Introducing a voluntary typo in the code so that you actually have to fix it manually to recompile? I can somewhat understand software packaging as value you might sell a customer into, but Rod and friends are just about to cross the line with this decision.

SpringSource is running the serious risk of making some aggregators very happy or – worse – to see their code undergoing a community fork. For sure, community love is going down the drain, then we’ll see. All this to secure what, in the end?

Europe and US: the impedence mismatch

Another great Think Tank has come and gone, and needless to say $DAYJOB kept me from writing a report. Luckily enough Larry Augustin beat me to it and came up with a post that’s nothing short of wonderful, the quintessence of it being how Europe and the US are barely speaking the same language when it comes to Open Source. My somewhat oversimplification to Larry’s synopsis:

  • Europe tends to consider dual licensing as “fake Open Source”. That quote alone, coming from a prominent guy from the French Public IT sector, made my day.
  • The sales model in Europe is heavily driven by VARs and SIs. Yours truly is not surprised, as that’s the very reason for giving birth to Sourcesense, but it was good to see our business model validated and blessed throughout the event.

Fabrizio, a true European despite his brand new US passport, adds some interesting comments, noting how you need to be in the US if you want to create a successful software company, so much that a number of Europeans actually crossed the Ocean and went to the valley. Can’t argue with that, but at least now we know the reasons why, and it’s probably a good time to ask ourselves if software companies are the way to go anyways. It has been pointed out at the event how the VC model helps building product-oriented businesses in the US, yet what I’m questioning with my European hat on is whether the venture attitude is building value for customers: yes, it’s a rhetoric question as you should know by now that my answer is no. Finally, I won’t miss to address in a future post the objection from Fabrizio about the “services don’t scale” mantra (should you unsubscribe now, know that the answer is they do scale, and they scale sustainably).

This Think Tank wrap-up wouldn’t be complete without noting how I had a wonderful time in Paris, and how it’s hard to give enough kudos points to Andrew Aitken of Olliance and Alexandre and Celine Zapolsky from our fellow colleagues of Linagora. Needless to say, I’m looking forward to meet all the Think Tank folks in Napa next year. And you should be there as well.

Sustainable software, part IV: Commercial Open Source redemption

Previously, on Sustainable software:


Making money on software alone is going to be increasingly hard as real world economics kick in. Open Source keeps on gaining momentum per se, yet Commercial Open Source doesn’t seem to go beyond mimicking traditional license-based business models with some Open Source frosting, proving it is not sustainable in the long run. Commercial Open Source is an accidental oxymoron.

When I was a student I did my share of summer jobs, mostly by helping a bookshop with a summer booth by the beach. On a very hot summer my employers thought they had the great idea of selling books by the kilogram: I was given a huge kiosk with lots of remainders, a scale and a couple of banners prominently showing we were going nuts.

The first week, we were novelty, I had serious problems keeping up with the frenzy and the owner was walking on sunshine. A week later the business dried up, we barely survived the summer season and my employer was spending revenues on anti-acid: customers realized that it was still just books, and we didn’t consider how motivating people to buy bulk quantities didn’t quite fit with tourists looking for the casual book and not exactly fancying heavy shopping bags on their evening stroll. People found out they were getting a better deal from the booth next to ours who was still going old school, who happened to have a better choice of titles and who consistently kicked our backside night after night: can you say fundamentals?

The important lesson I learnt is that marketing can only get you this far. It is not that hard to come up with a nifty idea to attract customers, but if you forget that at the end of the day it’s all about converting visitors to customers, which in turns requires proving you have something valuable to offer, you’re just building on sand. The sizzle is just not enough.

Commercial Open Source reminds me of my summer on a beach. Sure enough, it still manages to line up a number of interested prospects, enticed by the idea of a new way to distribute software liberating from proprietary clamps: unfortunately interest typically lasts until the salesman comes to visit. Chances are the guy has been building a career in proprietary software, and all he knows about his product is that it has something to do with computers, and what is still missing to nail the quarter. In or about slide number 10 the prospect wakes up and understand that the if you filter out “Open Source” from the pitch, the whole yadda-yaddas and blah-blahs are just the same old proprietary kool-aid he’s been through for ages: he still has to pay per CPU, he still doesn’t get any flexibility and he’s still going to be locked in. Ahyeah, the Open Source pixie dust is there but what gives in the end?

I’m sorry folks, you don’t build an industry with this. Unless you manage to prove your worth, budget owners are not going to pick up the tab, and your worth is seriously challenged if a free alternative is up for grabs somewhere. You can concentrate as much as you want in adding hoops to entice your customer to buy the proprietary version of your code, but you should also be aware that you will be pushing a boulder up the hill the moment your prospect understands that he has really been tricked to think he would have been in a different position, whilst that’s not really the case.

I want to be optimistic, in the end, and this is why I believe that there might be a sustainable model for Commercial Open Source, even though it will require a serious rethinking of what we have seen so far. My 2 eurocents would be:

  • Ditch the traditional proprietary approach for your paid-for alternative. Realize you just can’t take any Open Source advantage away from the customer, unless you’re fine in being on a level field with proprietary predators. A first, yet important, step in this direction would be abandoning pricing strategies bases on something that’s not really tied to a production cost for you, such as servers, CPUs or users: a key advantage of Open Source is the flexibility you get the moment you need an additional server – taking a key differentiator away is not going to help.
  • Be a blockbuster and work on volumes. If you get to be a leader in your space, you are going to be the strongest incumbent ever. If you manage to get that far, and you have a clear, upfront and value-driven commercial proposition, there is no need for hard sells. Just resist the temptation of being greedy, and then you can just sit back, relax and wait for your fax machine to be clogged by purchase orders from those who really don’t feel like being without official support.
  • Don’t be shy of value added services. Training, development support and consultancy are not exactly swear words and it’s something customers really value. All the big product guys are making sizable revenues for services, why should you be different?

Finally, a humble request. Please stop clogging my reader with stupid whines about users not paying your subscription and getting a free ride, making your software unsustainable as you can’t foot the developers bill. The market couldn’t care less about your developers’ kids in need of new sneakers or your VC craving about his next Lambo: the argument that someone has to pay for software development is one of the biggest straw man of Open Source – the market pays for value, and if you build very little, guess what, you won’t get more than peanuts. If your production model can’t leverage the community, if your marketing model can’t make the best out of the enormous free ride Open Source is providing and if your business model can’t stand the market and has to beg for charity, you will be shown the door pretty soon (unless you screw up real bad, in which case you can always resort to the US Treasury of course). We won’t miss you.

Sustainability is a serious issue: do not pollute it with empty rhetoric, let’s talk business instead. Let’s get back to basics and analyze why Open Source is the absolute best way to produce software, and a great money making machine if used appropriately. Food for another post (or two).

Sustainable software, part III: The anomaly of Commercial Open Source

Previously, on Sustainable software:


Viability of license-based business models is challenged by basic rules of economics. A proprietary software model is still possible, but it requires a barrier to entry based on customer satisfaction rather than fences and lock-in: in a collaborative world aggressive and predatory tactics motivate alternatives, making barriers weaker, not stronger. There is still room, however, for a proprietary licensing model focused on customer satisfaction, constant reality check and openness.

So what about Open Source? We will see shortly why it still matters and how it makes for an excellent set of business models, but this post is dedicated to long overdue rants about what goes by the name of Commercial Open Source, something I believe we will consider as a transitory anomaly in a few years from now.

Definitions, first: I know there is no common ground here, but allow me to define Commercial Open Source in this post as a business model based on customers paying a fixed or recurring fee to a vendor to use software that, give or take a few details, is also available for free and as Open Source. The value proposition, and I know I’m oversimplifying but I believe most readers know the drill anyway, can be based on FUD (warranty, indemnification, support), ease of use (better packaging, faster updates), more functionalities (widget frosting) or enabling of aggregates (avoiding the non-permissive licensing reciprocality).

I believe this model is not sustainable (from Wikipedia: “Sustainability, in a general sense, is the capacity to maintain a certain process or state indefinitely”), that is it doesn’t work in the long run as it fails to build barriers to entry to maintain artificial scarcity. The FUD argument is an insurance model with no defense from competition: anyone can provide warranty, indemnification and support, regardless on their actual role in creating or maintaining the software. Moreover, as insurance is a virtual good with no duplication cost, competition is likely to spiral prices down. Ease of use or better functionality require a good dose of what Fabrizio would call funambolism: the barrier to entry is challenged by the “good enough” on one side, and by itches the community itself will scratch on the other. Enabling aggregates might work a tad better, but it is, really, a niche.

As the intrinsic challenges were not enough, Commercial Open Source is committing suicide by failing to deliver, getting the worst out of traditional proprietary software predatory tactics and overall falling flat in building a durable relationship with customers. A structural reason for that is the role of capital, as most Commercial Open Source companies are VC-backed and their sole goal is paying back investors in the shortest possible timeframe: when exit strategies become the real mission of the company, customers are in for a rude awakening.

Weakness of the business model does the rest: to start with, a large number of Commercial Open Source vendors are tricking customers by renting instead than selling software. That is, if you buy the premium version you actually haven’t bought diddly-squat:if you fail to renew the subscription, you have to downgrade to the Community Edition or whatnot. Consider the irony: if you decide to “support” Commercial Open Source, you find yourself in a situation that is potentially way worse than with proprietary licenses where, at least, you get a perpetual Right to Use. And don’t get me started about the big hit and miss of support, as I stopped counting the horror stories I’ve been through with customers: that will make for a nice book when I retire.

Then what about RedHat? MySQL? The next Open Source company going for the mythical 1B (someone will for sure get there, my bet is on Funambol)? Exceptions, coincidences, anomalies. Sometimes planets do align, and the choice of the right product for the right market at the right time will make a recipe for success of the oddball. That’s far from being a sustainable and reproducible business model, though, something I’ll try to address in the next posts.

Sustainable software, part II: Proprietary, with a clue

Previously, on “Sustainable software”:

Only scarcity generates economic goods, that is goods that have economic value (we don’t pay for air and seawater). Digital goods such as software can be infinitely duplicated at zero cost, so they need a form of artificial scarcity, such as obfuscation and limited access, to justify a price tag. Artificial scarcity, in turn, needs a barrier to entry to resist the attack of competitors and alternatives: traditional barriers such as monopolies, complexity and lock-in are challenged by people scratching their own itches (Open Source) or by the intrinsic lack of complexity in building software (DYI).

At the end of the day it takes just Economics 101 and a pinch of common sense to realize how the software industry has an intrinsic problem. It is interesting to note how software has been digging his own grave by failing to provide enough value: the good news is that once you isolate the cause, you have a chance to find a cure. Which means there is hope for a license revenue model, after all, but it needs to be carefully thought out.

Let’s get rid of exceptions, first: there will always be the unprecedented case of a genius providing exactly what the market needs, at the very right moment. She will be able to charge loads of money, dictate her own conditions and get filthy rich in no time flat but, from a big picture perspective, we shouldn’t let exceptions distract us from business plans: chances for a software house to make billions overnight are as slim as the odds to be a professional sport player (as pointed out by the first commenter to this post). Sure enough, Tiger Woods is making millions by the minute out there, but would you let your child put all eggs in one basket to pursue a professional sporting career or would you rather suggest a plan B in terms of higher education and backup plans?

If we focus on the changes of average Joes out there willing to make a living out of software licenses alone, there is only one way to look at it: the business plan has to ensure barriers to entry are there to stay. If the barrier to entry is strong enough, very few will be motivated to build or market an alternative, and licensing money will keep on flowing. Now how do you do that? My personal recipe for a commercial/proprietary company looks like this:

  • Find a sweet pricing spot. Software has been plagued by questionable pricing tactics (predatory, supra competitive, or both). Pricing is your best friend if you play by market rules, and your worst enemy if you use it to gain a short term advantage. In a connected world, alternatives are one click away, but there is very little motivation in looking for (let alone building) an alternative if the price is just right, and even more if you err on the cheap side.
  • Link cost to value. What’s the deal with extorting money for non-production servers? What’s the point in counting CPUs or user seats when we are talking cloud computing and distributed environments? If your application is stupid enough to be clustered only as master-slave, don’t you feel ashamed when you require customers to pay an additional license for a node doing nothing but homework you should have done yourself? As a customer, I’m happy to pay (a fair value) for something that will cost you to provide, but the moment you cross the thin line between upselling and milking, I’ll be on the market.
  • Embrace openness. Your software will most likely have defects and bugs, and there is a good chance I will have to extend it to suit my needs. Don’t get in the way: give me extension points, and give me the ability to fix the problems I find (or pay someone to do it for me). Yes, I might screw up the system, and in that case you will be perfectly right in turning your back on me me, but aren’t successful relationships supposed to be based on trust? Protecting your source code from appropriation is fine, but you can easily accomplish that without obfuscating it and prohibiting me to work with it: if you obfuscate, I will start questioning what you might have to hide.
  • By all means, do not open source it. Give me a free alternative, and you can kiss your money bye-bye. Don’t let it be an excuse to ignore Open Source, though: chances are you will be using a number of Open Source components, and it will be very shortsighted not to have a stake in the commons. You want to contribute to those components, and you might even consider Open Sourcing the most general bits of your application, but you should never, ever have the full enchilada up for grabs. You still want to foster usage, of course, but there is a number of ways to do that, such as free licenses for non-commercial endeavors or individuals. Your licensing scheme needs to be liberal, but your revenue stream has to be protected.

Once again, please note that the following rules apply to a commercial and proprietary software house looking for a license based revenue model, and they are based on the general assumption of a cool software product (which is very hard to find these days). Future posts will analyze scenarios for a number of Open Source models, starting from what I believe is the biggest anomaly to date: Commercial Open Source.

Sustainable software, part I: The software value conundrum

After my last post on software sustainability, I had a number of conversation that are prompting me to clarify what I mean when I talk of sustainable software. I’m starting to jot it down, but it makes for quite a long read, so I thought it would be better to split it in a number of posts. Let me start with my very own take of the problem in front of us, that is the software value conundrum, or how software (let alone Open Source Software) hardly possesses any face value per se.

The “get filthy rich” recipe of the software industry has always been about near-zero production costs: once you have a product, all you need is a marketing & sales budget, as the marginal cost of production approaches zero. This perfect economy of scale makes for a great business model on paper, but is very hard to achieve and even harder to defend in practice: to start with, you need to be innovative enough to create a nearly monopolistic scenario to pull it off, something that is not impossible to attain if you are sufficiently creative and brave to generate a need or a niche (operating systems, relational databases, search engines…) that will allow you to create artificial scarcity and ask for a price. Yet if creating innovation isn’t that hard after all, the problem comes in defending the initial monopoly from the market fostering alternatives, competitors, or both: so far, the only deterrent are barriers to entry which, in software, proved to be the weakest link.

We buy houses, cars, computers and groceries. We don’t build them because we recognize the effort required in producing or delivering goods, and we realize it would be a lot harder for us to do it ourselves. The barrier to entry is steep and sturdy, as we are unlikely to learn about welding and build a car in our backyard or devote time and land to grow our own wheat, crush it to flour and bake it. We see value in those who venture into complex endeavors: we are ready to reward them and only a handful of us are prepared to climb the vertiginous barrier to build alternatives. Most of all: we easily understand how the unit of goods we are buying has been costing money to be produced and delivered to our doorstep. Sanity check: we see enough value in the effort required to produce goods that we consider morally and ethically wrong to steal it.

That’s not the case for software anymore. Open Source has shown us how the barrier to entry for software is just a narrow trench, not quite a Maginot line. Obfuscation isn’t enough, and makes us uncomfortable in that the hood welded shut takes away too much. The alternative of building software ourselves is compelling enough nowadays: with hardware prices plunging and connectivity everywhere, all a software house needs is a smart guy and a workstation (not to mention as we all know on the Internet nobody knows you’re a dog). Do not even bother with distribution: we know very well that there are nearly no costs involved in producing a marginal unit of goods. These factors, combined, make the dream business model go down the drain. The barrier to entry is just too easy to overcome, so much that sometimes you don’t need the strong motivation of a competitor attacking the incumbent: scratching your own itch is enough, especially when you consider how Open Source will help you find others with the same problem and happy to share their findings and work with you.

Sanity check, again: let me oversimplify what Helen Nissenbaum wrote in ”Should I copy my neighbor’s software?” (but don’t let it be an excuse for not reading it): do we have strong moral objections towards those who copy digital assets, be it music or software? Apparently that’s not the case, yet the law is exactly the same. This is, if you want, the anthropologist dismissal of artificial scarcity: in the end, it just doesn’t work.

Where does this all leave us? My very own conclusion is that basing a software business on licensing revenues has a very slim chance to succeed, let alone when Open Source is part of the picture. The good news is that there are ways to make money with software (and yes, even getting filthy rich is an option). But that will have to wait for another post.

Beware of the Leopard…

So I heard about CMIS (no link as I have no idea of what the authoritative source is). I went to look at the spec. I searched. And browsed. And downloaded. And it wasn’t the right stuff, so I browsed again. And downloaded again. And unzipped. And finally I (think) found them. And I was excited in discovering the Internet equivalent of “the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard’“.

Not exactly a good start, methinks.

Sustainable software? Look down under!

A few months ago I was sipping a drink with friends, and I was asked what would I do should I ever leave Sourcesense. I answered that I would hope I’d make enough money by then but assuming it wasn’t the case, I would most likely start a new company or, failing that, I would contemplate moving to Sidney and send my CV to Atlassian.

There is more than surfing Australian waves in my admiration for that company: I’m watching with great amusement the debate on Open Source sustainability, how making money is tied to proprietary extensions, how Open Source is not a business model, and all the yadda-yadda that regularly pops in when someone dares to comment how, really, the Emperor is not wearing any clothes. Such commentaries are being filed in the “Firm grasp of the obvious” category, but they make for a fun read anyways: meanwhile, as the Commercial Open Source world is out there frantically looking for the Holy Grail of software sustainability in an open and collaborative ecosystem, it seems to me that a happy bunch of Aussies are filling it with Foster’s and passing it along.

While most Open Source companies try to make money by providing a free all-you-can-eat Sunday roast buffet, as long as you carve it yourself and bring your own gravvy, Atlassian is showing the beef by providing great food at reasonable prices, all the gravvy you want and a tab with no hidden charges, surprises or discretionary service fees attached. Not to mention a recipe book and access to the grill to cook to your own taste. Can you really argue with that?

I know, I know: it’s not Open Source, you need to pay to play and the ball is theirs. Yet their model is so upfront and clear that it feels like a breath of fresh air when compared to the amazing lot of commercial Open Source/crippleware in disguise out there:

  • pricing is clear and reasonable, mesured on real value instead than on what it takes to send a salesman to your premises to measure your spending ability, then provide you with a quote.
  • you pay for what actually drives value. Do you have 50 developers with software installed on their machines to build and test locally, plus a build and a staging server? No problem, here goes your unlimited free development license key to go along with the one you purchased for your production server.
  • do you want to tinker with the source code? You get all you need and then some to fix stuff yourself. And no, they won’t withdraw support just because you messed up with the code.
  • do you fancy ecosystems? Just browse the amazing number of plug-ins, add-ons and extensions that have been built by developers all around the world, or just ask for assistance in the user forums.
  • do you want to use their technology to support your Open Source effort? Here, get a free license and have fun. Oh, and by the way have a look at the notable number of contributions that Atlassian did to Open Source software and libraries they are using.

Can your Open Source vendor do this? I will need a few more fingers (and toes!) than I have access to if I wanted to count how many quote-Open Source-end-quote companies out there are doing their best to play the baitware game, providing astonishly little value for amazingly high prices and playing hardball with customers. While the Commercial Open Source world is talking about hybrid revenue models, here comes a pragmatic shop that just nails it. May I suggest analysts to pick up the phone and give Mike Cannon-Brookes a call?

What’s in a name?

Everyone and his dog his talking about Chrome. I’m probably not going to try it anytime soon: there is no Mac version for the time being, and Chromium is supported on spotted Macs only (yours truly is still striped and happy about it), but I can see exciting times ahead.

What I find pretty odd is how no one on my radar bothered to comment about how Chrome is a poor choice for a name, given how the same term has been used extensively for a key part of XUL, the UI toolkit behind Mozilla/Firefox. Chrome is so relevant to Mozilla that it even became a URL scheme, and I find hard to believe no one at Google was aware of potential name clashes.

I guess the humongous amount of money the Mozilla Foundation are getting through Google is going to make things easier, but I can’t see how that can be a good name that doesn’t piss Mozilla fans off. Does anyone remember how Firefox had to change name twice due to trademark issues and general brouhaha from the Firebird open source database community? History repeating itself, methinks, but it would be fun to see the Mozilla Foundation sending a Cease & Desist letter to Google, footing the bill with Google’s own money.

On an unrelated note, however, I’m just flabbergasted about big G’s marketing technique and tactics. I won’t believe even for a split second in the leaked email story, but I can definitely see how using comics was pure genius. I couldn’t say it any better than Bertrand:

Using graphics to explain stuff is obviously the best way, but the dynamics of the cartoon format (varying image sizes to emphasize importance, repetition of similar patterns and shapes to create a familiar universe in small steps) go much further than just combining images and descriptions. Not to mention the fun factor in reading it – everybody knows that people learn better when fun is involved.

I’m convinced – we need more of this to explain our often complex software systems.

Now excuse me while I go find a designer to write our next pitches as comic books…