Blogging on FOSSBazaar

In case you didn’t notice, yours truly finally managed to accept the invitation from Martin Michlmayr and I’m now blogging on FOSSBazaar as well. The rough plan is to move my rants on Open Source and IT governance over a more appropriate and specific place, with the occasional reblogging over here. I’ll see you there!

A blast!

I’m slowly resurfacing from the Sourcesense day, our first (and highly overdue!) all-company meeting where we celebrated our third birthday and took the chance to finally put names to faces, enjoying an off-site day with presentations, brainstorming sessions, great food and a wine tasting contest, a big party in downtown Milano with many friends showing up, and a hackathon day in the Milan office which has been extremely productive in mixing together our impressive set of expertise and skill, learning from each other and finding lots of common ground.

Adrenaline has been keeping me up to what have been two very intense and gratifying days and, as any organizer, I have been completely blown up by the end of the meeting, looking forward to a week-end full of sleep to recharge batteries. I’m still in recovery mode, but I would do it again tomorrow and I am indeed looking forward to the next venue; I think I have learned more from these mere two days than in three years’ worth of hard work in creating a diverse, international and kick-ass team. It was just amazing to see how people coming from different backgrounds have been able to come up with a common vision, a set of shared values and a clear direction for the future.

The Sourcesense management will have a lot to digest in the upcoming weeks to keep up with the very high expectations from the team (my plate is now full with many action points), yet I’m confident this meeting has been a turnaround point to all of us, and a way to sit down and admire the impressive achievements we managed to score during the past three years. I still don’t know – though I’m going to find out soon – what parenting means, but I have to note how filled with pride I have been in seeing how we managed to grow from a guy, a rough plan and a DSL line to a room packed with people coming from all over the world and working towards a common goal.

Thanks to all who attended: it’s been a real blast, and I can’t wait to do it again.

La Divina Commedia – geek style

Much like Dante, I now know what Heaven and Hell feel to a poor geek like myself.

Hell: I was in Oxford to deliver a talk at an outstanding event. Woke up early and refreshed, enjoyed a great breakfast, finished up my slides, put my computer to sleep and walked to the conference. Went to the podium to test my Mac with the projector.

Opened the lid, it didn’t wake up.

Hit a few keys, still no joy.

Oh well, that happens, just reboot the thing and move on.

Not really, it doesn’t boot up.

Cold shivers run through my spine as I extract the battery, to no avail.

It gets scary when the PRAM/NVRAM reset doesn’t seem to help, nor does it doing the same to the PMU: all of a sudden, I realize my Macbook just turned to the most expensive brick ever, the only good news being how incredibly helpful are people at the Oxford Computing Centre: minutes before my presentation starts, my machine has been disemboweled, the hard disk ripped off and put in an external enclosure connected to an iBook G4. Luckily enough, a somewhat dated PDF version of my slides is there, so my talk can proceed.

I still have to manage two days away from home, without a computer, uncertain about what’s left on my data and even unable to recharge my iPhone as the machine is so screwed up the USB plug doesn’t get any juice. If it wasn’t for the great guys at OSSWatch letting me borrow their workstations and notebooks, I’d be probably hanging from the Radcliffe Camera.

Heaven: mortal remains of my laptop are sitting in my bag when I get the following e-mail from the awesome Slicehost team:

At approximately 21-Oct-2008 00:00 GMT the server your slice is on stopped responding to our monitoring systems. After several attempts to powercycle the server it became necessary to fully swap out the server hardware. Your slices are now running on new hardware. We apologize for the trouble, contact us with any questions.

All of a sudden, I start to think how I would feel if I still had to manage my own hardware – that frantic feeling of whether we will find the culprit, find someone who is able to take a day off and drive to the colo, install the spare parts, hoping backups will work. All this now turns into an email along the lines of “your server b0rked, it’s now fixed”: long live the Cloud! If only we could do that for laptops…

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.