Politics vs Innovation

An excellent article about how internal politics in large companies stifle innovations getting to market. A lesson that still hasn't been learnt 40 years on!

Working Boats

On Friday, I spent the day helping out on a historic narrowboat. BCN 108 is a butty built in 1883, that is being used to carry aggregate (sharp sand and gravel) from the quarry to the asphalt/concrete works 4 miles downstream in Uxbridge. A butty is a traditional boat without an engine that was pulled behind a tug. Here is BCN 108 moored up at Uxbridge waiting for the loading to begin.

BCN 108 moored up

I arrived at about 7:20am just in time to find the fire lit and the kettle on. Peter, who owns BCN 108, had spent the night aboard. He and Richard take 55 tons of aggregate down every Friday. Richard also takes around 60 tons of aggregate down on Thursdays in his boat Arundel. On Fridays Arundel pulls BCN 108.

Kettle's on

You may be wondering why a 100 year old boat is being used for the supply chain of a modern asphalt factory? Well, as well as the two traditional boats, there are two modern boats. The boats are significantly greener than sending the cargo by road. Unfortunately the modern boats weren't designed quite right. They were specified to take 100 tons each, but they didn't take the canal quite into consideration, and when filled with 100 tons, they simply sit on the bottom! So they take 70 tons a run, and the traditional boats take the extra load.

Richard loading 30 tons of sharp sand into Arundel

When I was a teenager, I used to take holidays on traditional narrowboats, and the opportunity to see one in action doing something useful was irresistable. The main work is the loading and unloading, interspersed by a very relaxed trip down the river. I was sent on ahead to set the two locks (get them ready). Here we are going through Cowley Lock.

Arundel and BCN 108 in Cowley Lock

The unloading is the real hard work. The main part is done by a JCB, but in between Peter and I got into the hold and dug the sand out of the corners!

Unloading the sand at the Hanson plant

I entertained Peter with a couple of tunes on the whistle. Since it was St. Georges Day yesterday, I mainly played English tunes - the Morpeth Rant, Not for Joe and Barham Down.

Peter about to take the boats through Uxbridge Lock

It was an enjoyable day - the weather was perfect too - and it was interesting to wonder if the green revolution might bring back some more use of Britain's canals - typically freight on a narrowboat uses 1/5 of the diesel of the same freight on the roads.

Why the Internet is Anglican

Today is St. Georges Day, the patron saint of England, and I think its an interesting day to reflect on why the Internet is Anglican. For those of you who don't know what I mean by Anglican, its the term that refers to the many churches around the world that inherit their approach from the Church of England.

Before I explain what on earth I'm talking about, I'd like to explain what brought this to mind. I was reading Joe Gregorio's blog entry "The Atom Publishing Protocol is a failure". To summarize, AtomPub "hasn't seen the level of adoption" that Joe "had hoped to see at this point in its life."

I think this is probably common to every protocol inventor, except maybe Tim Berners-Lee, Jon Postel, and a couple of others. After all, how many protocols could be the main protocol used for everything on the Internet:

• BEEP. Well this has gone very quiet, but this used to be considered a contender.
  
• SIP. A while ago, everything was going to work on SIP - IM, Voice, Video, SOAP/SIP, the works. SIP is actually a very nice protocol for bootstrapping peer-to-peer comms.
• SOAP. Nuff said.
• AMQP. Designed to be the main protocol for everything businessy.
• XMPP. With enough extensions you can do anything.
  
• and of course: HTTP. Of course this is the protocol on which everything works. But it hasn't got complete domination yet!

Now let's go back to my analogy of churches. Most churches have a single approach, almost like a single protocol. If you go into a Catholic church in one country, its very similar to a Catholic church in another. The Anglican church is pretty unusual in that it varies massively. In some Anglican churches you can find a Tridentine Mass. This is the old Catholic service from the middle ages which until recently wasn't allowed in most Catholic churches! In other Anglican churches you will find the opposite end of the spectrum with very Protestant forms of worship.

Maybe its in the English character to have a wider, more open view - it might explain why we have a Turkish/Roman soldier (St. George) as our national Saint!

Back to AtomPub. Joe says:

"There are still plenty of new protocols being developed on a seemingly daily basis, many of which could have used AtomPub, but don't."

In my view, Joe is expecting too much. I think AtomPub is a fantastic protocol, and I see it succeeding. But I start off from a basis that any protocol that gets even a small market share of the Internet is a success. No protocol is ever going to take over the Internet, and there will always be plenty of different approaches to do the same thing. That is simply the nature of the Internet.

Open Source discussion

I recently took part in one of Dana Gardner's podcasts on Open Source and Cloud. You can listen to the podcast here.



The discussion kicked off because of JP Morgenthal's comments that Open Source is harmful to innovation. I think its an interesting point, but surprisingly I don't agree. I guess the most obvious point is one I forgot to make in the podcast: just look at Open Source software and see the innovation. There is an incredible store of innovation in Open Source. Just try to think of 5 innovative proprietary systems and then 5 open source. I think you'll find it easier to think of 5 open source innovations.

Anyway, listen to the podcast and let me know what you think.

Fareham Folk Festival and Barham Down

I spent some of the weekend at the Fareham and Gosport Folk Festival, where I joined the "Festival Band".

The Festival Band idea is really fun. The simple idea is this: get together with some people you've never met before, learn some tunes you've never played before, and by the end of the weekend perform them live on stage!

I have to give huge credit to Laurel Swift and Jennifer McGlone the band leaders, who taught us the tunes and arranged the performances. In the end we had a band of about nine people playing: three whistles, one mandolin, one concertina, two fiddles, a hammered dulcimer and a guitar.

Unfortunately I don't have a recording of our final performance but I hear someone took some video and plans to post it. In the meantime here is a recording of one of the tunes, Barham Down, which is a triple-time hornpipe (3/2), presumably from Kent where Barham Down is.

Open Source vs JDK Bloat

One of my long-running annoyances with the Sun Java Development Kit (JDK) has been the "bloat" that each excessive JDK has added. I don't really care about megabytes but I do care about code, and each JVM has added more and more functionality, often conflicting with existing open source packages.

Here's my problem: Sun controls what goes into the JDK through the J2SE JCP process. And Sun has added more and more packages into the JDK while making minimal changes to the JVM and core language. And in my mind, this is completely the opposite to what should be done. A simple example is script language support.

For years, there has been a completely portable way of adding scripting language support into Java using Apache BSF. Sun added scripting support to JDK6 and broke a whole bunch of existing BSF applications. BSF not only worked, but it also had a more permissive license than the JDK and is completely portable back to ancient versions of the JDK, meaning that you have much portability. The same applies to StAX, JAXB, JAXWS, and a whole lot more. In the case of StAX, its probably worse, because the Codehaus Woodstox project is far better than the one Sun ships.

In fact, it almost seems like the JCP has gone out of its way to find good Open Source projects, and then take the exact same function and replicate it then add it to the JDK. In some cases, Sun has worked with the community - the java.util.concurrent code is a good example. But even in these cases, many people had to rely on the backport code because they wanted to run on JDK 1.4.

Meanwhile, the core language has creeped along. It took a long time for generics to arrive, and it will be a long time before I can use closures - by the time my users are all on the right JVM I'll probably be retiring!!

Anyway, enough moaning! What is the solution? Sameera, one of the WSO2 team has pointed out that under OSGi you can control which packages from the JDK are exposed to your code. Now I can have complete control and if I want to use Open Source equivalents I can. Even better, I can protect against future JDK revisions by strictly controlling which packages are exported.

Update:
Sameera has blogged this:
http://tech.jayasoma.org/2009/04/exporting-public-jdk-packages-in-osgi.html

http://tech.jayasoma.org/2009/04/exporting-public-jdk-packages-in-osgi-2.html

You simply need to set the

org.osgi.framework.system.packages

system property.

If you want to see the packages exported by default, pull up your OSGI command line:

java -jar org.eclipse.osgi_3.4.0.jar -console

getprop org.osgi.framework.system.packages

If you want a simple example of the bloat here is the difference between 1.5 and 1.6. As far as I know, the annotations are the only real "core language" change and all the rest of the code is also available in Apache or BSD licensed Open Source code.

> javax.activation
> javax.annotation
> javax.annotation.processing
> javax.jws
> javax.jws.soap
> javax.lang.model
> javax.lang.model.element
> javax.lang.model.type
> javax.lang.model.util
> javax.script
> javax.tools
> javax.xml.bind
> javax.xml.bind.annotation
> javax.xml.bind.annotation.adapters
> javax.xml.bind.attachment
> javax.xml.bind.helpers
> javax.xml.bind.util
> javax.xml.crypto
> javax.xml.crypto.dom
> javax.xml.crypto.dsig
> javax.xml.crypto.dsig.dom
> javax.xml.crypto.dsig.keyinfo
> javax.xml.crypto.dsig.spec
> javax.xml.soap
> javax.xml.stream
> javax.xml.stream.events
> javax.xml.stream.util
> javax.xml.transform.stax
> javax.xml.ws
> javax.xml.ws.handler
> javax.xml.ws.handler.soap
> javax.xml.ws.http
> javax.xml.ws.soap
> javax.xml.ws.spi