Beyond the Code

The GNOME project has released version 2.26 of its eponymous open source desktop environment for Linux. It adds support for MAPI to Evolution, the messaging client in GNOME, allowing it to work with all versions of Microsoft's Exchange Server. It also adds the ability to open Outlook mailbox (.pst) files.

While "release early, release often" can make reporting on new versions of open source software an exercise in trivia, this time the changes introduced could increase the level of adoption in companies that haven't previously had many Linux desktops. Before this latest release, Evolution could only talk to Exchange servers using a SOAP interface, which wasn't supported on all versions of Exchange, and didn't provide the same level of functionality as MAPI, Microsoft's native messaging protocol. Now Evolution should be able to connect to any version of Exchange Server.

Exchange is used in many large companies for email and calendaring, and being able to continue using it after migrating to a Linux desktop removes another big barrier for some organisations. Native MAPI support will help, but don't underestimate how useful the PST support will be: The standard edition of Exchange has a database size limit which varies with version, which applies to the total size of all mailboxes on that server. I assume this is there to make you pay more for the Enterprise version of Exchange, but its real effect in some of the companies I've seen Exchange used in is to have very small per-user mailbox limits, and have mail archived in PST files, either on the users' machines or a network drive.

If rip-and-replace was a realistic strategy, changing from proprietary to open source software would be easy. It's not — so much of a company's information is tied up in proprietary formats, and is still needed — so a smooth migration path is the only answer to open source adoption.

While the negotiations and prevarications over the IBM purchase of Sun Microsystems continues, all the rest of us can do it sit and wait to see what happens. I don't really see what IBM will get by buying Sun that it couldn't have some other, cheaper way, but since I don't own shares in either company, I have little more than a passing interest in whether it's a good deal financially.

I do care more about the effect the merger would have on the industry, and software development in particular. Both companies have a large influence on what happens in the non-Microsoft development world, and between them have Java toolchains more or less sewn up — Eclipse, originally an IBM project, and NetBeans, Sun's own IDE, have seen off most proprietary Java development tools.

This would be more of a worry if IBM and Sun were still locked into a proprietary software model themselves, but thankfully they've spent the past few years trying to out-open source each other. The result of this has been some great tools for creating all sorts of applications, all released under decent licences — not least Java itself.

If the merger does go ahead, the last thing developers have to worry about is losing their favourite tools. Free licensing means they can't be taken away, no matter what.

Analyst firm Ovum has predicted that Android, the Google-led open source mobile OS, will appear on Netbooks before too long. It's hardly the most incisive of predictions (and it's been made before) -- most netbooks already run Linux, and Android is just a Linux distribution optimised for low-power systems.

Android has been criticised for having a non-standard development environment. Its native development tools use the Java language, but don't provide a full Java platform, so you can't just take any existing Java application and run it on Android. This is because Android has been designed to squeeze into the smallest hardware specification possible, rather than through some desire to control what runs on the platform.

There are other distributions of Linux for netbooks available which are closer to a standard distribution. These have virtually none of the drawbacks of Android, but will require more powerful hardware. If you buy a Linux-based netbook today, it will come with one of these distributions. What, then, does Android have to offer netbook users? Longer battery life, a simpler interface, a more responsive system? Maybe all, or none of these things.

Whether Android is a good choice for a netbook is not the issue, rather it's that netbook manufacturers have that choice. They can even choose to take parts of Android, add more conventional Linux components to it to increase the number of applications that will run out of the box. It's possible that proprietary operating system vendors would allow modifications on this scale, but they almost certainly wouldn't allow redistribution of the source code, and would probably still charge their per-unit licensing fee, despite the hardware vendor having done much of the integration work.

Netbooks have been an interesting development which have sold in markets where traditional notebooks wouldn't have. This means that vendors have been able to sell more units than might otherwise be the case, and for good reason: customers have been able to buy a device that better fits their needs than full notebooks or handhelds. Everyone wins. This wouldn't have been possible if the hardware companies developing these devices hadn't had an easily-modified operating system distribution available, or had to commit to per-unit licensing costs before it was clear netbooks were going to be a success.

It's this ability to take an idea and see where it goes that's the power of open source software. If some manufacturers try putting Android on their devices, rather than a heavier distribution, that's up to them and the market will decide whether it's a good idea. Having to stick to one operating system vendor's idea of what a device should be capable of would prevent hardware innovation, and that stops people buying the device they want.

The OpenStreetMap project (OSM) now has over 100,000 registered users, as of 16th March. If you're not familiar with OSM, it's a free, editable map of the world, aiming to do for geographical data what Wikipedia did for encyclopaedias.

(Declaration of interest: I'm both a contributor to OSM and a member of the OpenStreetMap Foundation)

Since the project was started less than five years ago it's gone from being derided as completely unworkable to rivalling commercial geodata sets where its coverage is good. The number of people contributing data is still a fraction of the total, the two are related. Bulk imports from other sources have helped increase the coverage and quality of OSM's data, but it still needs volunteers to get out there and check what's on the ground.

Microsoft has announced the release of a plug-in for Eclipse which adds Silverlight development capabilities to the open source IDE. The plug in, Eclipse4SL, is itself available under the Eclipse Public License, an OSI-approved open source licence. While this is incompatible with the GPL, it's still a good licence, just with weaker copyleft provisions.

While I haven't tried Eclipse4SL itself, the feature list looks good, and makes Eclipse a viable platform for developing Silverlight code on. Despite being written in Java for a cross-platform IDE, it will only run on Windows, but you can't have everything -- and since the source code is freely available there's no reason someone else can't port it to other platforms.

Microsoft's motivation for wanting Silverlight development in Eclipse is clear: It wants its technology to be used as widely as possible, and giving developers who don't use Visual Studio tools to code for Silverlight should increase adoption, however marginally.

Look closer, though, and there's a clever piece of legal sleight-of-hand going on. While Microsoft funded the development of Eclipse4SL, it didn't do the work itself, nor has it released the code itself. Instead, it contracted French Eclipse specialists Soyatec to write the code. In the terms of the EPL, Microsoft is not a Contributor to the project. Microsoft has plenty of smart developers who could have done this coding. Sure, they may not know the Eclipse APIs as well as Soyatec's staff, but learning a new API is never that difficult, and once released as open source, the code can be improved by other contributors who may know the best way of coding for Eclipse.

Read the text of the EPL, and the reason becomes clear. Clause 2b states that "each Contributor hereby grants Recipient a non-exclusive, worldwide, royalty-free patent license under Licensed Patents". Had Microsoft been the Contributor, it would have essentially agreed to licence whatever patents it claims covers Silverlight. Of course, Microsoft wants to do no such thing, hence this little manoeuvre. We have to assume Soyatec holds no patents over Silverlight.

All this shows is that while Microsoft pays lip service to open source software, interoperability and innovation, it still wants to have the ability to hit others with patent lawsuits. You could use this software, paid for by Microsoft, aimed at increasing use of a Microsoft technology, and still end up facing a patent infringement claim, despite not breaking the the terms of the licence the code was distributed to you under.

If Microsoft wants its open source efforts to be taken seriously, it has to comply with the spirit of open source, not just the letter of a particular licence.