Ivan Ristić: May 2008

I've run into a very interesting presentation from Ivan Krstić (via Risque Management) who, as director of security architecture for the One Laptop per Child (OLPC) project, designed a new code execution platform—Bitfrost—to avoid the security issues that plague the desktop systems in use today. Bitfrost uses capabilities to restrict what each program can do, irrespective of the user account it runs under. You may be familiar with the concept from SELinux, GRsecurity or AppArmour, or, more recently, Caja.

By designing Bitfrost, OLPC did something remarkable: it gave up compatibility (with other platforms) in exchange for a secure execution environment. It's a decision so unusual that it must be applauded. So it's no wonder that Ivan resigned in March of 2008 after OLPC had appeared to have changed focus and Windows XP on its laptops became a reality. Judging from the status page, it appears that Bitfrost is not complete yet, so I wonder how it will progress now that Ivan is not with OLPC any more.

The presentation is full of interesting observations that I fully agree with. For example, the main point:

We have failed as an industry, and modern desktop security is completely broken as a result.

And this statement:

Key symptom: desktop security relies on the user to make informed, sensible choices... About things they don’t at all understand.

And this one:

So we weasel off responsibility to the user, stick our head in the sand, and pretend this was the right thing to do. But the user knows as much about computer security as they do about gravitational waves, closed strings and D-branes.

Please go and read the presentation for yourself so that I don't have to quote it here in its entirety. (What's a D-brane?)

Backward compatibility, by the way, is the main reason why everything is so insecure today. We made these very bad choices years ago, when the circumstances were vastly different, yet we are refusing to put things right today. It is a genuine challenge, even if you put the interests of various industries aside. If you were to come out with a perfectly secure operating system today people wouldn't jump to use it only because it's secure. Only Apple could have pulled that off, by doing things right in Mac OS X, but they wasted that opportunity.

The really sad fact is that the next opportunity to fix things is passing us by at this very moment. The whole world is moving to the Web, where desktop applications don't matter, but, instead of doing things right, we are just moving from one insecure platform to another.

I've come to the conclusion that people (e.g. developers) must be forced to do the right thing by not allowing them to do the wrong thing. The low adoption of the Java security model is a perfect example of this. Java has had a very good capabilities-based security model since version 1.2 (released in 1998), but hardly anyone is using it today. Why? Because it's optional.

I first encountered (and used, in production) Spring Framework in its pre-1.0 days, and it was love at first sight. I loved it because of its vision, a very good design of its MVC and database libraries, and, most importantly, quality (I am sure it has bugs, but I am yet to encounter one). The licence, Apache Software License version 2, was right too. I had even been a step away from joining the development team, but ultimately decided to focus on ModSecurity instead. Spring had a lot going for it: the Java server-side programming was in a state of disarray. We needed a beacon to guide us.

Fast-forward a few years, and we have Spring firmly established as the leading player in server-side programming. Then, a few more years down the road, the bloat is starting to appear, after the development team (apparently) deciding small and focused is not beautiful after all. In parallel with the evolution of the framework, Rod Johnson (the author of Spring) grew his consultancy business, Interface21.

Then, the inevitable happened. The success of Spring became too tempting. Interface21 sought venture capital, changed its name to SpringSource, and went on to buy Covalent (or merge with, depending on whom you ask), a quiet but persistent company in good standing with the community.

My fear, when I heard the news of funding, was the same as Corby's (from the post at InfoQ):

If anyone had the ability to grow organically, I thought Interface21 did. VC don't give you money unless they're going to grow you 20X. I am very concerned about seeing an explosion of Spring subprojects that lack the quality or the relevance of Spring core. And VC don't give you money unless you're going to cash out. I don't see Interface21 operating as a standalone IPO, so that means they will be actively seeking acquisition. I hate to see one of the big guys get ahold of this very independent entity. I wish the Interface21 folks great financial success, but I hope Spring does not turn into a bloated, slow-release monster. I have already heard rumors that Benchmark Capital is pressuring Rod Johnson to change his name to something more kid-friendly.

Things started to go wrong after SpringSource decided to experiment with their licensing choices. They introduced a number of proprietary products and started using other open source licences. Their most recent product, SpringSource Application Platform, is licensed under GPLv3, in stark contrast to ASLv2 used for the framework itself. (GPL essentially allows businesses to retain control of the code base.) The changes made many members of the community feel insecure, and lead to heated exchanges on the forums. Prior to the changes the company was often called a darling of Open Source (it sounds like something I would have said), because they were a rare example of a business (the Interface21 consultancy) built around the restriction-less Apache Software Licence. I can only conclude that, under the changed circumstances, their business was not growing fast enough, and that they felt that they needed to do things differently.

This story is a clear demonstration of the challenges facing open source commercialisation, especially when funding comes into play. Where we previously had a clean separation of the project and the company, now we have a company that is using the project to build a proprietary business model around it. They may still be contributing to the open source parts—today—but do you trust them they will continue to do so? SpringSource are saying they are on the same path they have always been. Maybe they believe it, but they are not on the same path, and the users see it. SpringSource are saying they will keep the Spring Framework alive and open source. I actually believe they are being honest when they say that. But I also know that people come and go and that, eventually, the prosperity of the company may matter more at some point in the future. There is no doubt that Rod Johnson cares deeply about the project, but there is also no doubt the VC company behind the funding cares only about the money.

Let me be clear when I say there is nothing wrong with making money of your work, be it open source or not. It's the change of direction that's making everyone nervous. For many people open source is about freedom and certainty. They don't want to have vendors to depend on. They've chosen to work with Spring Framework on the basis it's vendor-free. So it's not surprising that they are starting to feel twitchy now that they've realised the company behind their favourite project is a vendor too. If SpringSource want to preserve their hard-earned credibility they need to act fast to insulate themselves from the core Spring Framework project. It's certainly a tough thing to do (convincing the VCs, I mean), but it's the only thing that would bring the user trust back and preserve the developer community (as in those developing the framework itself).

Ultimately, it may not matter. Spring Framework has already built a momentum. It is a very good product, so there is no reason to not use it. But there's no help but feel a bit cheated. We are never going to have the same warm feeling about Spring, as we did back in the old days.