Mark Shuttleworth | here be dragons

Congratulations to the Bazaar team, who just released version 0.12 of my favourite free software distributed revision control system. Well done Martin, John, Robert, Aaron & co.

The big focus as they move to 1.0 is performance, and a key part of that is the performance of revision control across networks. Since the whole point of internet-based collaboration is to share code and innovation between developers in different parts of the world, network performance is a key issue for the team.

Bazaar has the neat property that you can publish your branches using only a web server, with no special features. Just exposing the files as a read-only tree over HTTP is enough to publish your branches. That’s nice and easy to setup – combined with SFTP support it means that just about anybody with some sort of personal web space can publish code in a format that is easy for other developers to collaborate on – with full revision control for everybody.

The disadvantage of this is that HTTP publishing (or any sort of virtual file system) requires that files be read one-at-a-time, with all the work being done on the client side. That means it’s difficult, or perhaps impossible, to make the whole thing super fast. For that, you need a server which understands “branches and changesets”, so that you can talk to it using a specialised protocol with meaningful questions and answers like “what’s changed in this code since I last came by and asked?”

This latest version of bazaar includes just such a smart server. It’s really easy to setup – if you have an ssh-based account on a machine, you can work with your remote branches very efficiently now – in fact, it’s much faster checking for updates using this smart server than using something like rsync.

This is just the first cut – over time, I think the smart server will become more capable, the conversations more “high-level” and, as a result, the performance even better. Robert Collins has written up a comprehensive page on how to extend and improve the smart server – Python coders with an interest in revision control should check it out. This complements his article on extending bzr itself with plugins. There are a lot of very cool plugins already – Jelmer’s “SVN branching and committing from BZR” plugin really shows how we can bridge the divide between different version control systems with bazaar, which has an underlying model that is a superset of the other major free systems.

I’m sure many folks are aware of the tension between Mozilla and Debian over the use of the name “Firefox” for the web browser package. A good exchange of comments between Chris Beard of Mozilla, and Mike Hommey of Debian highlights some of the challenges involved.

Both groups really, genuinely mean well. I know this because I’ve spent some time working with both of them. Both care deeply about free software and both want to see the world improved through the wide availability of high quality software that comes with the right to change it. So it is a little frustrating to see this level of public tension between two groups that have come to represent, each in their own way, something iconic about free software.

First, let me say that both groups are being entirely reasonable about their positions. Debian has every right to insist that it have the freedom to ship the package in the form that it deems most appropriate for its users, and Mozilla has every right to protect its trademarks.

It’s worth bearing in mind that Debian’s position on both free software and trademarks is very complex and not entirely consistent. Consider the recent decision to ship Etch with proprietary software built in. Firmware is in most cases X86, PPC, Mips or ARM code (architectures Debian supports) for which real source in C exists – but that source code is of course not provided. Also consider Debian’s own trademark policy which, while liberal, still restricts what can be done.

My goal in our own discussions with Mozilla has been to establish that it really is possible for a distribution that cares about free software and Mozilla to agree on a framework which gives us both what we need. The Ubuntu team went as far as preparing packages without the Firefox name in case we were unable to reach an agreement – but in the end the fact that we kept the lines of communication wide open meant that we were able to find a middle ground and ship the packages we want while still supporting the Firefox name and Mozilla’s work. Nobody sold out.

I hope that the lead we have established with Ubuntu and Mozilla will benefit Debian, establishing a precedent that allows both groups to get what they want. But I also think that it may just be that the needs of the two camps are incompatible. And that in itself is a reasonable thing.

What I would like to ask for, should that prove the case, is that both sides are as gracious about it as possible. There’s no need for name-calling in either community.

Remember – we are all committed to 99.9% of the same vision. We have far more in common than our colleagues and counterparts at Microsoft and Opera and other proprietary browser vendors. Let’s make sure the tone and the scope of the dialog between us reflects the full reality of our alignment (and in truth also our disagreements) rather than just the specific small stone in one shoe. The media love to play up differences – of course they do, it makes for a damn good story! Don’t let that be how the discussion is ultimately remembered.

Should Debian settle on IceWeasel, thats fine and dandy and does not mean that anybody should call them “fundamentalists”, as I’ve seen happening. Neither should Mozilla’s position give anyone in the Debian camp cause to imply that Mozilla are corporate junky marketroids. They simply are not. They’re damn good browser innovators, and they publish their code under free software licenses because that’s what they think is the right thing to do.

Excellent work happens on both sides, with real collaboration in the best spirit of free software development. I would in particular like to highlight the amazing work that Mike Hommey does on the IceFox (:-)) packages in Debian. There’s a huge amount of effort that goes into testing, porting, reviewing, and generally being a good free software citizen on a package of this scale, and Mike and others in Debian do a phenomenal job. In his analysis he points out that the Ubuntu and Debian packages are very similar – I think that’s a credit to Ian Jackson, who I know spends a lot of time passing Ubuntu changes to Debian, trying to make sure that there’s no unnecessary divergence between Debian and Ubuntu.

It’s a very important thing to know that an inability to agree on something – even if that thing turns out to be a dealbreaker – doesn’t mean that the other person is a bad person. Give credit where it is due, state your differences simply and without prejudice. Debian and Mozilla should be able to work together effectively on a browser, even if they can’t agree on a way to call it Firefox.

If we want the world to embrace free software, we have to make it beautiful. I’m not talking about inner beauty, not elegance, not ideological purity… pure, unadulterated, raw, visceral, lustful, shallow, skin deep beauty.

We have to make it gorgeous. We have to make it easy on the eye. We have to make it take your friend’s breath away.

That’s why I’m thrilled with the work of some of our community artists. Check out this logo from Who (ignore the scaling, view it directly):

If you are of an artistic bent then I would urge you to get involved with the Ubuntu Art Team, and peruse or join the Ubuntu Art mailing list. There is also a new site for community-contributed artwork, being developed by Brandon Holtsclaw and I think currently available at art-staging.ubuntu.com though it will move to art.ubuntu.com and get more horsepower shortly.

Of course, “pretty but unusable” won’t work either. It needs to be both functional and attractive. Rather than bling for bling’s sake, let’s use artistic effects to make the desktop BETTER, and obviously better.

This is a challenge we (the free software community) share with scientists too.

I had a great coincidental chat with a guy from Imperial College, London, recently. He lectures in a course which teaches scientists and engineers how to communicate with the rest of humanity. This is close to my heart – I love the bleeding edge, physics, computer science etc, and I can’t stop my imagination from turning ideas into exotic works of mental art. But mental art isn’t something you can convey very easily – it’s in your head, after all. If we want people to get excited about science we have to show them what it’s makes possible. Imperial College teaches people who love science how to make it fascinating for everyone else too – something NASA could take to heart.

Similarly, I met up with Susan Greenfield from the Royal Institution – not a loony bin for inbred monarchs, but a public forum for the demonstration, discussion and discourse on science that goes back to the days of Humphrey Davy and Michael Faraday. In those days, science was hot entertainment for the gentrified classes, who would gather of an evening in formal dress to listen to scientists talk about the magical world that was opening up under their microscopes and instruments. We spoke about a number of things but I thought that their mandate was most similar to that of the Hip2BeSquare project which I fund in South Africa, which brands the idea of being “smart with your life” for students and pupils in SA (think about it – which pays off more in your life, an extra hour of math or an extra hour on the football field… it takes a lot of math before the marginal benefits line up and it’s time to hit the fields).

All of which goes to say that messaging is important – learning how to “show off your best stuff” is an essential skill, and I hope the free software community will take that to heart.

Wow, it feels like just a short while ago that a few like-minded Linux lovers gathered at my house to talk about the project that became Ubuntu.

Now we’re thinking of having a “user and business” conference, aimed at bringing together the people who deploy and manage Ubuntu in the real world (well, in the USA in particular, but let’s think globally) with those who help to produce it. The big question is – who would want to come? In order to run such an event we would need about 500 people to attend. It would be a 2-day conference (with additional days of workshops and tutorials separately, probably) and would likely be run in close proximity to another big event. The cost per delegate would be around $700. We’d bring together companies offering services based on Ubuntu, developers and ISV’s building solutions on it, and end users who just want to squeeze the most out of it. It would be a traditional style conference, with tracks and keynotes etc.

We’re testing the waters and keen to know what sort of level of interest there is in this idea. So – please leave a comment on this blog post if you have suggestions, ideas, or would attend such an event. Or feel free to email ubuntuworld@ubuntu.com with your comments if you prefer that.

The “character” I like most about the free software community is that it is not afraid of setting itself audacious goals. I like that in a person, especially when combined with a cunning plan, good ethics and a capacity for work, and if you think of the free software community as a gaia-like “living creature” it very much has those same traits.

As a community, we’ve done amazingly well in terms of challenging the historical epicenter of computing – the supercomputer and data center – and driving change there. Linux now represents a healthy and growing share of infrastructure in large organisations globally. Apache and other infrastructural components have established the new de facto standard for software in the back office: freedom. It would be easy to declare victory.

But, as anybody who flies in the backseat of a military plane to land on a carrier and declare victory will tell you, it would be premature.

The real challenge lies ahead – taking free software to the mass market, to your grandparents, to your nieces and nephews, to your friends. This is the next wave, and if we are to be successful we need to articulate the audacious goals clearly and loudly – because that’s how the community process works best.

With that in mind I think I’ll serialise in this blog a speech I’ve enjoyed giving recently, which lists a set of challenges and goals, obstacles and mountains to be overcome on our way to making free software the de facto standard for home and office computing. History shows that the free software community can organise itself to attain any well articulated goal around which there is broad consensus of it’s merit and difficulty. Perhaps these ideas will be food for thought in those lofty circles 🙂

Since the call for topics went out there’s been a steady flow of interesting suggestions for the next release of Ubuntu (likely to be 7.04, code name “The Feisty Fawn“). I’ve spent some time reviewing those and proposing a few of my own :-)… as have other members of the Tech Board and community.

The best place to see how it’s shaping up is to look at the current set of topics for the next Developer Summit that takes place Nov 5-11 at the Googleplex (yay bandwidth!) in Mountain View, California. If you will be close by, subscribe to a few of those topics, and register to come (Launchpad account required) to the summit and tell us how you want Feisty to rock!

Someone joked about giving Jane the title of “Chief Wiki Officer”. We have about 7 wiki’s internally and there’s no end in sight! I think we could consolidate them and use access controls to keep various communities distinct but – for those of us who have to roam across them – integrated. This got me thinking about the limits of current wiki technology. Is there any comprehensive list of wiki platforms?

At the same time at the Foundation in Cape Town we are busy gearing up to commit about R30m (about $4.5m in today’s terms) to create a complete set of school books for all subjects in the South African curriculum in wiki format. I got to wondering which format we should use. There’s a lot of action around MediaWiki (used by Wikipedia) but one of our goals is to be able to print low cost books – real books with tables of contents etc on real paper – for those schools which don’t have bandwidth or PC’s. Can MediaWiki produce DocBook output? Or should we be using a different collaborative platform altogether? I remember hearing about a DocBook wiki system, but can’t find any references to that now.

So here’s the question – if you wanted to write a book collaboratively, with rigorous access control and revision control but also with chapters and sections, and an index and tables of contents etc – what platform would you use (free software greatly preferred, and open format’s required, of course :-)).