Category: Opensource

Agoramancy? A Sunday afternoon ramble

I don’t know about you, but I spend a fair amount of time looking at things that emerge from open source communities, be they free-as-in-freedom or free-as-in-gratis. At least one of the reasons I do so is to try and figure out what happens next. Agoramancy? Who knows. [For those who care about these things, the word “agoramancy” yielded precisely one result via Google.]

I used to track something called LiveSupport, which lately became CampCaster. If you get the chance, go there and take a look. Alternatively, I’ll save you some of the bother and quote some of the interesting bits from their site:

  • Never heard of Campcaster? Here’s the elevator pitch: Campcaster helps you run your radio station. Do automated broadcasting and live studio playout in one system: schedule your broadcasts from the comfort of your own home with the Campcaster Web component, or do dynamic live shows with the Campcaster Studio desktop application.

    What’s the big deal about this release? We’ll cut to the chase: Campcaster 1.1 is the first release that is stable and feature-complete enough to be used in production systems. Indeed, the Campware implementation team will be helping to roll it out to multiple radio stations in Sierra Leone later this month. Other major radio stations are starting to adapt Campcaster to their needs: Austria’s Radio Orange is adapting the playout system to work with its digital archive, while in Hungary, a network of independent radio stations is integrating Campcaster’s storage server into its IKRA project, a generic public website engine for radio stations.

    “Awesome! Where can I get it?” you ask. The first thing you should know is that Campcaster only works on Linux. We recommend Ubuntu Dapper or any other Debian-based system.

    If you have an Ubuntu or Debian system, then just click here for installation instructions. Otherwise, click here to download.

This gets very interesting. In the lead-up to Y2K, despite everything the consultants did to raise FUD amongst the billpayers, many Eastern European and South Asian countries stood their ground. Houston, we don’t have a problem. Why? Because they computerised too late. The advantage of No Legacy.

When you look at the countries that are really making use of opensource, a similar pattern emerges. People who find lock-in a luxury too far. The infinitesimal cynic in me sees PL 480 equivalents where people are forced to use lock-in products and services, where governments set vendor locks in concrete. But then I remember 1974 and Daniel Patrick Moynihan writing what was then the world’s largest cheque ever, for $2.2 billion, and then presenting that cheque to Mrs Gandhi to clear the PL 480 residues.

Back to the point. See what the CampCaster site says:

The first thing you should know is that Campcaster only works on Linux. We recommend Ubuntu Dapper or any other Debian-based system.

If you have an Ubuntu or Debian system, then just click here for installation instructions. Otherwise, click here to download.

Is this the shape of things to come? Only Linux. With a recommended distro. But possible with other distros. Only Linux.

Linux is definitely becoming more and more mainstream, and we will see variations on this type of announcement all the time.

Take The Venice Project as an example. For years people have been telling me that there’s nothing they can use to watch TV on Linux, even though I showed them magazine articles that said they could, and even tried to show them the software. Tried. And failed. But that was in the past.

What now? What does the Venice Project say about this? I quote from their site:

  • Does The Venice Projectâ„¢ work on the Mac or Linux?

  • We’re working hard on a native Macintosh Intel version and expect it to be available in the next few months. Currently the application works fine under Bootcamp but not under Parallels; it needs to access the graphics processing unit (GPU) for some of its operations, and Parallels does not support that at the moment.
  • A Linux version is also in the works.

Folks, we’re heading fast towards a world where Linux, OSX and Windows will coexist. Where the market will force people to make substitution-level interoperability something “normal” and to be expected. Where industrial-strength design coexists with elegance and coolth.

And I for one am looking forward to that new world.

A coda. You know, when IBM sold their PC division to Lenovo, I heard rumours that they did it because the management were sick and tired of the fights between their Linux guys and their Windows guys. I dismissed it as the fiction it was. But now I wonder.

Musing about opensource: The threat is stronger than the move

What do you do when you’re told to take it very easy, when you’re told to make “slow” a polysyllabic word? If you’re me, and you also have a deep-seated protestant work ethic in you, you struggle. Big time.

Well, that’s what I did for a little while last month, struggling to get past the denial stage. I really didn’t know how to do nothing. Then, come the new year, I had a Road To Damascus experience and then I settled down into an easy rhythm of eat-read-sleep-potter-about-aimlessly, interspersed with the real joy of spending time with my wife and kids. While on the subject of convalescence, my thanks to all who sent me get-well-soon messages. As you can see the messages are working…

Now to the point of this post.

As part of the pottering-about-reading-aimlessly time, I came across this post by James McGovern, whose blog I get to reasonably often.

Read the post, it’s worth it. James commented on a perception held by some developers that many opensource communities aren’t particularly welcoming, and that developers are put off joining as a result.
And it made me wonder.

I’ve always believed in a community participation rule of thumb, something I’ve written about before here and here. The numbers tell the story:

  • For every 1000 people who join a community:
  • 920 are lurkers, passive observers
  • 60 are watchers, active observers capable and willing to kibitz
  • 15 are activists, actually doing something
  • …and 5 are hyperactive, passionate about what they’re doing, almost to a point of obsession

And this is what I was musing about.

Does it really matter, the number of people who actively contribute to an opensource project? Is there something about the way opensource communities work, something that will always ensure that a very small number are the hyperactive core?

The more I think about it, the more I believe that there’s something important here. Linus’s Law is about eyeballs, not hands, and it’s for a reason:

  • At the heart of every successful opensource community is a small cottage industry. And it is this cottage-industry mindset that makes the community different from other “commercial” ones.
  • The core doesn’t have to scale. The core needs to behave in such a way that Linus’s eyeballs are attracted, and this is done by upholding the right values.
  • Jerry Garcia and gang only needed to make sure that Grateful Dead concerts had “taping rows”; the number of people who sat in them was not relevant (although they were full). In a weird kind of way, the core is the band. The tapers are the activists. The kibitzers are the roadies and volunteers.
  • Together with the audience, they formed a whole and vibrant community.
  • Not everyone needs to be on stage for the community to work. In fact there isn’t space.

It is the freedom of access, represented by the taping rows, that really matters. That’s what makes opensource opensource.

Or, to take a chess analogy:

The threat is stronger than the move.

Form follows funding

I was looking for Doc’s D-I-Y IT article in Release 1.0, couldn’t find it in a shareable form and went for a ramble on the net as a result. Found Doc’s IT Conversations piece on the same subject. Read it. Again. And I saw the Stewart Brand quote again.

Form follows funding.

Fascinating.

So, when we buy opensource, what form will the output take?

I shall work on this. And delve deeper into Stewart Brand.

A coda: Doc has seen the fact that I am struggling to find the Release 1.0 article, and has sent over a copy. I hope to be able to link to it soon.

Four Pillars: Preparing the Foundations: On opensource

As part of Foundation and Empire, I have already signalled that I wanted to look at the impact of opensource on the IT construction industry (something Doc Searls covered in detail a few years ago in Release 1; I hope to link to it sometime tomorrow).

Humour me and come along for a slight detour.

In a recent post, I tried to connect up TheManInTheDoorway with Ed Byrne and Hugh Macleod, emphasising the need to de-commoditise. And today I came across this in Aqualung. DefDiff or the Definition-Differentiation model.

Now the debate really intrigues me, and will influence how I write the Foundation and Empire piece. Because there’s something I don’t understand. That’s when I can learn something.

Why do we need a model that helps us throw away internally built components and replace them with externally sourced ones, as a means of moving from differentiation to commodity? Why should we worry about the “legacy” constraints of existing APIs and formats?

I’m not questioning the process. I’m questioning the need for a new model. I think we already have a valid model.

It’s called opensource. I have always believed that opensource should never be about deep differentiation, in fact that opensource works best when the problem being solved is shared by many. When the problem is a commodity.

Maybe it’s me that’s warped. I want to commoditise the problem. Then the solution must of course be commoditised.

Once people realise that opensource is the new outsource (yes I know I’ve said it before, but so what?) then this becomes easier to grasp. [An aside: Wouldn’t you just love to go to your boss and say you’ve outsourced 50,000 part-time jobs s/he never knew you had?]

Platform and device and UI/browser independence come as standard when you buy opensource. So you don’t worry about legacy conflict, provided you have the right principles in place in the first place.

You know, sometimes I think we can rewrite enterprise IT strategy to just one line:

Make it demonstrably easier to consume opensource day after day.

You get the ability to throw away the commoditised. You get to lower maintenance costs on the soon-to-be-commoditised. If someone else gets there first your costs of acquisition are lower. You can keep concentrating on that which differentiates you.

Which leads to an interesting corollary: Only keep the problems that are unique to you. That’s a whole new subject in itself.

More later. In the meantime, Malc, Ric, thanks for taking me somewhere else in my quest for the Foundations.

Opinions, comments and flames welcome. Almost requested.