Simon Phipps's Blog

July 2003 Archives

Sun and Open Source - Development, not Deployment

In his recent posting on java.net Alan Williamson asks how open source software can ever be profitable. I believe his thinking confuses two different issues - how software is developed and how it is deployed. In some contexts they are the same thing, but in a growing number they are completely different. In the difference lays the answer.

I believe the best way to understand open source is as a methodology. It's essentially been in Sun's genes for 20 years, and Sun has repeatedly tried to fuse open community development and the creation of broad commercial markets in project after project. Today Sun sees open source as the best way to build great software in co-operation with the rest of the massively-connected community, given the commercial freedom to do so. We employ engineers to work on open source projects. We support the open source community; we deliver value to customers; we protect, facilitate and enfranchise both.

Open source is a software development methodology - that's why you need the source! The openness facilitates a developer community. It's not primarily intended as part of the deployment vehicle for end users, and that's where the risk lies. The developer-friendly features make it all seem so tempting for deployers - control over the software, free code and no lock-in - but those things were put there for the developers, not the deployers. Obviously an open development community needs the source code to be under an open-access license and on a web site - otherwise how could it function?

When deployers decide to use the benefits that facilitate the developers as the vehicle for deployment, they will inevitably 'pay the price' somehow. They could pay by putting people into the open source community to act on their behalf, collecting the code and deploying it on their systems. Alternatively they could get community members procure, perhaps customise the code and then deploy the results. But an expert is always required. Sun's answer, the one most companies want to hear, is "we join the community so you don't have to" - and in the process we indemnify you, we get your bugs fixed and we hold your hand.

For Sun, open source software development often makes perfect sense as part of our business plan. Our story is not "we want to bring it down", it's "we are a member-practitioner, and here's how we do it". Sun works in the Open Source community, and then adds value with packaging, documentation, support, long term insurance that the project will continue, indemnification and more, so that the Sun customer can feel secure in adopting an Open Source technology, and feel that they are justifiably receiving a value for paying money to Sun. Doing these things to enable deployment doesn't impact the 'freedom' of the development community - it just that the freedom that enables development isn't applicable to most people deploying.

Sun invests more in open source than pretty much any other company, has more reliance on open source in its products, and uses that experience to deliver the value customers want. I might summarise this by saying "Sun is the industry's biggest open source company" and "we joined the community so our customers don't have to" and currently most importantly "we're taking the risks so our customers are indemnified".

So how does open source make money, Alan? Well, simply by letting businesses make great products that people want. Development and deployment aren't (always) the same thing.

[Also posted on Webmink : the Blog]

Getting ready for the big bang

Supernova is part of what The Register calls "a giddy social whirl of conferences and and other airmile aggregation opportunities". As most of the speakers have weblogs, we have the opportunity to peek inside and perhaps get a preview of some of the content.

Cory Doctorow has started an interesting thread, on a topic Liz Lawley hinted at a while back - whether always-on-ness is helpful or harmful. I remember the same questions about compulsive use of the PDP-11 when I was at university, mind you, so it's not a new question. Delegates at this event however will have an impressive array of alternative feeds even without leaving the event - a wiki, blog and blog aggregator just for the event, before they've event started reading speaker blogs and the like. Positive: If my speech is no good the delegates won't suffer (or even notice); Negative: My speech will have to be pretty compelling to even make people look up.

Mind you, if the have the HeckleBot Joi Ito writes about, being ignored will be the least of my problems. With WiFi becoming common at conferences, there's more and more back-chat going on live, and while I've been known to play too, I'm not sure it's altogether a good thing to turn a conference into a gong show.

Amy Wohl hasn't been blogging much lately, maybe because the fight with spam is becoming overwhelming. The worst part of the spam problem is the way some of the anti-spam tools are being deployed. I tried sending an e-mail to the committee I chair at OMA yesterday and was greeted with a bounce message thus: "554 SPAM-Relay detected". While spam is clearly a bad thing, software that assumes if can detect it 100% reliably without user confirmation is clearly deluded. The best server-side software I have found so far is MailScanner (written by my neighbour Julian Field), which is more a pluggable framework than a single solution. But with broadband access available, I prefer to handle it client-side. David Weinberger relies on PopFile, and so did I until I got my PowerBook and started using the Mac Mail.app, which has filtering built-in. Leaving the final decision to the user (even if it's to blindly ignore things tagged as spam) seems vital to me.

It goes further than just spam. One of the discussions here on java.net is about inappropriate postings. As well as discussing whether it should be personality dominance, community consensus or technical merit that sets standards (all three can be the same thing, of course), Clay Shirky's excellent essay on groups reminds us that those who ignore history are doomed to repeat it, and that spam is just the harbinger of the sort of group behaviour that killed Usenet for most of us. His suggestions on how to design for success bear investigation.

This post has already gone on far too long - following Anil Dash's lead I should probably stop here and not be too much more ADD. Assuming my attention span will hold that long, my talk at Supernova will be about the way becoming massively-connected is having consequences at all levels in both technology and society. The network is now the computer, and the effects - always-on-ness, appropriateness of communications, a gong-show attitude and more - are inevitable, important but hopefully transient if we can learn from research and history. Much more of an issue for me is how the development and maintenance of standards will evolve. Massively-connected development is in beta-test; massively-connected specification is in early alpha-test. These are the key trends.

[Also posted to Webmink : the Blog]

Open Design

I have commented to a few people that Blogging is a Big Deal. Not, I hasten to add, because I think that anything more than a core of special people (special can have many meanings, but I like Halley's article...) will ever decide to participate in a meaningful way in that specific activity. Rather, it's because of the work that it's catalysing, both extending blogging and going way beyond, as Jorgen Thelin hints and Tim Bray explains.

Weblogs are, in my opinion, the most successful application of web services to date. They have been successful because a combination of social factors and sufficiently OK technology have come together at the right time, and because they have a universally almost-agreed format for the content of the conversations. Most of the fuss in the world that calls itself web services has been about the plumbing, and no doubt one day there will be wonderful things happening there, but for now the big win has been for the application with a standard content format, transferred using whatever communications method comes to hand (for the most part, HTTP - XML-RPC has and continues to be crucial too, and while I don't share Tim Appnel's distaste for mentioning it I do share some of his reservations about its future).

That's why I consider the current online debate about whether XML-RPC should be used for nEcho divisive (Update: and is seems Sam agrees). It does a great job baiting certain individuals but fundamentally nEcho has to be about a content description first and then later about a way of communicating it.

Blogging was already a fascinating social crucible, empowering millions to express themselves and thousands to engage in distributed, accountable conversation. Now it's spawned a unique technology encounter. Open source has given us a development methodology for the massively-connected era. We now see the spontaneous formation of a potential design methodology for the massively-connected era.

[Also posted to Webmink : the Blog]

Sun has an Open Source Info Site

Storm in a Soup Bowl

While totally invisible to the bulk of humanity, there's been a storm in a soup bowl of late as the Great and Good of blog-tech have been focussed into a Wiki to design a successor to RSS and the Blogger API - the name 'Echo' has been mooted as a placeholder. The choice of a Wiki is itself interesting, as Clay Shirkey notes, and from the messages its host has added to many pages the soup bowl has been straining at the seams. I've tried hard to keep up with the discussion, as has Norm, but the sheer pace of the hive mind is too much for anyone with a day job to cope with.

The reason for the storm? Well, As Clay hints, one or two of the well-known figures in blog-tech have taken the creation of a personality-reduced space as a personal affront. I really don't want to get into the personality side of things, although I have been surprised and saddened to see the venom that's been expressed in some postings by people I respect.

One issue that needs considering though is whether this project is there to offer an agreed unification of RSS 0.9x, 1.0 and 2.0 (and stop there) or whether it's there to go further. The project's motivation page says a lot on this, and comments moving towards each extreme have been popping up all over, but I think it's clear the answer lies between the extremities. I completely agree with Sam that seven elements is the magic number for things people can manage to agree about in one breath.

But when it comes to not inventing things, I'm not so sure. Mark Pilgrim is on the ball as usual, and the point here is that there are so many exciting things that will come from an agreed content format for this slice of web services. I don't just mean threading and other features for blogs either. If we don't co-operate now on defining the format, someone will inevitably come along and lock us in. So I still support 'Echo' and I hope you will too, preferably by actually joining in.

[Also posted to Webmink : the Blog]

This work is licensed under a Creative Commons License.