The webzine itself is gorgeously laid out and the art in it is very good indeed. Congratulations to Chrisdesign (of gimpforums.de fame) in this great initiative, long may it continue!

Mal Minhas of the LiMo Foundation announced and presented a white paper at OSiM World called “Mobile Open Source Economic Analysis” (PDF link). Mal argues that by forking off a version of a free software component to adjust it to your needs, run intensive QA, and ship it in a device (a process which can take up to 2 years), you are leaving money on the table, by way of what he calls “unleveraged potential” – you don’t benefit from all of the features and bug fixes which have gone into the software since you forked off it.

While this is true, it is also not the whole story. Trying to build a rock-solid software platform on shifting sands is not easy. Many projects do not commit to regular stable releases of their software. In the not too distant past, the FFMpeg project, universally shipped in Linux distributions, had never had a stable or unstable release. The GIMP went from version 1.2.0 in December 1999 to 2.0.0 in March 2004 in unstable mode, with only bug-fix releases on the 1.2 series.

In these circumstances, getting both the stability your customers need, and the latest & greatest features, is not easy. Time-based releases, pioneered by the GNOME project in 2001, and now almost universally followed by major free software projects, mitigate this. They give you periodic sync points where you can get software which meets a certain standard of feature stability and robustness. But no software release is bug-free, and this is true for both free and proprietary software. In the Mythical Man-Month, Fred Brooks described the difficulties of system integration, and estimated that 25% of the time in a project would be spent integrating and testing relationships between components which had already been planned, written and debugged. Building a system or a Linux distribution, then, takes a lot longer than just throwing the latest stable version of every project together and hoping it all works.

By participating actively in the QA process of the project leading up to the release, and by maintaining automated test suites and continuous integration, you can mitigate the effects of both the shifting sands of unstable development versions and reduce the integration overhead once you have a stable release. At some stage, you must draw a line in the sand, and start preparing for a release. In the GNOME project, we have a progressive freezing of modules, progressively freezing the API & ABI of the platform, the features to be included in existing modules, new module proposals, strings and user interface changes, before finally we have a complete code freeze pre-release. Similarly, distributors decide early what versions of components they will include on their platforms, and while occasional slippages may be tolerated, moving to a new major version of a major component of the platform would cause integration testing to return more or less to zero – the overhead is enormous.

The difficulty, then, is what to do once this line is drawn. Serious bugs will be fixed in the stable branch, and they can be merged into your platform easily. But what about features you develop to solve problems specific to your device? Typically, free software projects expect new features to be built and tested on the unstable branch, but you are building your platform on the stable version. You have three choices at this point, none pleasant – never merge, merge later, or merge now:

• Develop the feature you want on your copy of the stable branch, resulting in a delta which will be unique to your code-base, which you will have to maintain separately forever. In addition, if you want to benefit from the features and bug fixes added to later versions of the component, you will incur the cost of merging your changes into the latest version, a non-negigible amount of time.
• Once you have released your product and your team has more time, propose the features you have worked on piecemeal to the upstream project, for inclusion in the next stable version. This solution has many issues:
  • If the period is long enough, your feature additions will be long removed from the codebase as it has evolved, and merging your changes into the latest unstable tree will be a major task
  • You may be redundantly solving problems that the community has already addressed, in a different or incompatible way.
  • Feature requests may need substantial re-writing to meet community standards. This problem is doubly so if you have not consulted the community before developing the feature, to see how it might best be integrated.
  • In the worst case, you may have built a lot of software on an API which is only present in your copy of the component’s source tree, and if your features are rejected, you are stuck maintaining the component, or re-writing substantial amounts of code to work with upstream.
• Develop your feature on the unstable branch of the project, submit it for inclusion (with the overhead that implies), and back-port the feature to your stable branch once included. This guarantees a smaller delta from the next stable version to your branch, and ensures you work gets upstream as soon as possible, but adds a time & labour overhead to the creation of your software platform

In all of these situations there is a cost. The time & effort of developing software within the community and back-porting, the maintenance cost (and related unleveraged potential) to maintaining your own branch of a major component, and the huge cost of integrating a large delta back to the community-maintained version many months after the code has been written.

Intuitively, it feels like the long-term cheapest solution is to develop, where possible, features in the community-maintained unstable branch, and back-port them to your stable tree when you are finished. While this might be nice in an ideal world, feature proposals have taken literally years to get to the point where they have been accepted into the Linux kernel, and you have a product to ship – sometimes the only choice you have is to maintain the feature yourself out-of-tree, as Robert Love did for over a year with inotify.

While addressing the raw value of the code produced by the community in the interim, Mal does not quantify the costs associated with these options. Indeed, it is difficult to do so. In some cases, there is not only a cost in terms of time & effort, but also in terms of goodwill and standing of your engineers within the community – this is the type of cost which it is very hard to put a dollar value on. I would like to see a way to do so, though, and I think that it would be possible to quantify, for example, the community overhead (as a mean) by looking at the average time for patch acceptance and/or number of lines modified from intial proposal to final mainline merge.

Anyone have any other thoughts on ways you could measure the cost of maintaining a big diff, or the cost of merging a lot of code?

On Wednesday morning (after SMASHED), we had to get to the new location for the conference. I missed the bus window of 8am to 9am, so I took a taxi, without knowing the address of where we were going, other than knowing that it was the “Gran Canaria university, informatics building”. Turns out that’s not enough information for a taxi driver Anyway, got there eventually, late for the opening session, and a little more expensive than expected. I also lost some change down the back of the bucket seat, so he even got a tip.

Anyway, the rest of the day went pretty well, and we had some great mobile related presentations (to compliment all of the other mobile related content in the conference):

• Multimedia in your pocket, by Stefan Kost: Nice presentation on using MAFW to build complex multimedia applications
• Designing Moblin-Netbook. A free desktop on a 7-10″ Screen, by Nick Richards: Great overview of the Moblin platform, and the design principles guiding it – from design requirements, personas, and dealing with constraints.
• Hildon desktop in Maemo 5 by Kimmo Hämäläinen: An overview of the Hildon desktop on a whiteboard by Kimmo.
• MAFW: the Media Application Framework for Maemo by Iago Toral: Drilling down into the details of MAFW.
• Why its easier to re-invent rather than participate on the mobile? by Shreyas Srinivasan: My favourite presentation of the day. Shreyas laid out what he had expectied from GNOME Mobile, the problems he encountered, his understanding of the issues, and some proposed solutions to those problems. All in 15 minutes. I really appreciate people who don’t pad out the content that they have to present and instead focus on making a high-impact presentation.
• GNOME Mobile BOF, led by myself: We talked about how far we’ve come, the original goals of the initiative, and identified a bunch of things that we can improve short-term and medium-term.

Had a great dinner again on Wednesday, in a tapas bar with some Red Hatters and Michael Meeks, and then on to the party. Wednesday night was the golf club party, sponsored by Collabora, with a free bar until 1 (of which I mostly did not avail – I was being good), and I was in bed by 2. It was a great party, and I picked up another couple of cyclists for the outing I had been planning for Friday, before they wimped out on me.

Anyway – that aside, Richard’s position is that it’s dangerous to include Mono to the point where removing it is difficult, should that become necessary to legally distribute your software. On the surface, I agree. But he goes a little further, saying that since it is dangerous to depend on Mono, we should actively discourage its use. And on this point, we disagree.

I’m not arguing that we should encourage its use either, but I fundamentally disagree with discouraging someone from pursuing a technology choice because of the threat of patents. In this particular case, the law is an ass. The patent system in the United States is out of control and dysfunctional, and it is bringing the rest of the world down with it. The time has come to take a stand and say “We don’t care about patents. We’re just not going to think about them. Sue us if you want.”

The healthy thing to do now would be to provoke a test case of the US patent system. Take advantage of one of the many cease & desist letters that get sent out for vacuous patented technology to make a case against the US PTO’s policy pertaining to software and business process patents. Run an “implement your favourite stupid patent as free software” competition.

In all of the projects that I have been involved in over the years, patent fears have had a negative affect on developer productivity and morale. In the GIMP, we struggled with patent issues related to compression algorithms for GIF and TIFF, colour management, and for some plug-ins. In GNOME, it’s been Mono mostly, but also MP3, and related (and unrelated) issues have handicapped basic functionality like playing DVDs for years. In Openwengo, the area of audio and video codecs is mined with patent restrictions, including the popular codecs G729 and H264 among others.

What could we have achieved if standards bodies had a patent pledge as part of their standardisation process, and released reference implementations under an artistic licence? How much further along would we be if cryptography, filesystems, codecs and data compression weren’t so heavily handicapped by patents? Or if we’d just ignored the patents and created clean-room implementations of these patented technologies?

That’s what I believe we need to do. Ignore the patent system completely. I believe strongly in respecting licencing requirements related to third party products and developer packs. I think it’s reasonable to respect people’s trademarks and trade secrets. But having respect for patents, and the patent system, is ridiculous. Let a thousand flowers bloom, and let the chips fall where they may.

So if you want to write a killer app in Mono, then don’t let anyone tell you otherwise. If you build it, they will come.

I am sure we will manage to get past $5,000, but I wonder if we will do it today? To help us put on this great conference, and help get some passionate and deserving free software hackers together, you still have time to give to the campaign.

Thanks very much to the great Free Art and Free Culture community out there for your support!

Update: Less than 2 hours after posting, Mark Wielaard pushed us over the edge with a donation bringing us to exactly $5000. Thanks Mark! Next stop: $6000.

We also concurrently opened the call for participation. Since we’re already a little late organising content this year, we’re going to have a pretty short call – please send abstracts for GNOME-related and cross-desktop content to guadec-papers at gnome.org before April 10th (midnight on the date line, I guess).

The procedure is going to be a little unusual this year because of the co-hosting of GUADEC with Akademy – a GNOME papers committee headed up by Behdad will be choosing GNOME-specific content, and a KDE equivalent will be choosing Akademy content, and we are co-ordinating on the invitation of keynote speakers and choice of cross-desktop content.

The thing that got me excited about this conference last yearn and the reason I was so enthusiastic about combining the conferences, is that cross-desktop content. The Gran Canaria Desktop Summit has the potential to be the meeting place for free software desktop application developers and platform developers, as well as embedded and mobile Linux application developers. We will have the people behind the two most popular free software development platforms coming together.

The conference is an opportunity to plan the future together for developers working on the kernel, X.org, alternative desktop environments like XFCE, application platforms like XUL, Eclipse’s SWT, desktop application developers and desktop-oriented distributions. I’m looking forward to seeing proposals for presentations from all over the mobile and desktop Linux (and Solaris) map.

So to your plumes! We’re not expecting abstracts to be works of art, but we are looking for thought to be given to your target audience and what you want them to get from your presentation. Compelling, entertaining and thought-provoking content will be preferred over “state of…” presentations, or other types of presentation better suited to blog posts. Knock yourselves out!

In the three weeks since the announcement of the launch of the campaign, we have raised almost $3,000 in community donation – mostly smaller than $50 – from 71 individual donors. Much of the credit for the campaign this year has to go to Jon Phillips of Creative Commons, Inkscape and OpenClipart fame.

The campaign has started earlier this year than last year, when we were really caught unawares by our difficulties in getting sponsors, and has lacked some of the frenzy of the last campaign, but Jon has been doing stellar work keeping the fire burning, and ensuring a regular stream of donations from supporters of projects related to Libre graphics.

It is hard to overstate the importance this conference has to the communities working on projects like Inkscape, GIMP and Scribus, among others, and to overstate the progress we have made because of these conferences in the past few years in the realm of graphics applications on Linux.

It’s useful to point out that in the Linux Foundation desktop linux surveys, the most popular applications which companies and individuals want for Linux are graphics applications – Adobe Photoshop, Illustrator, Premier, Autodesk AutoCAD, Adobe Dreamweaver and Microsoft Visio are the top 6 applications which people are missing on Linux. This conference is all about encouraging the development of applications destined to fulfil those needs. Also worth noting, when asked whether they wanted the applications above ported to Linux, or they wanted to use equivalent Linux applications where possible, a large majority want to use native equivalents, rather than ported commercial applications.

For any of you looking for a good cause which will go directly to supporting high quality applications that you use, I’d encourage you to contribute to the Libre Graphics Meeting. The conference is only as worthwhile as the people attending it, let’s ensure that we get a critical mass once again and provide energy and momentum to all of the participating projects for the coming year.

This also represents a very quick release cycle – under 1 year since 2.4.0 – which is good to see.

Any Inkscape people out there able to set me right?

One interesting drag & drop thing I love showing to people is dragging a chart created in Gnumeric into Inkscape – the drop is a proper SVG, and you can ungroup & manipulate individual elements from the chart in your favourite vector graphics application. Which is nice.

Continuing the series of articles I started last week (part 1, part 2), the next fall-out which has come from past Libre Graphics Meetings is the movement towards colour management everywhere over the past few years.

Let’s look back to where we were 3 years ago. Outside of Scribus and CinePaint, there was essentially no colour management in free software graphics apps, in spite of the existence of a high quality color management library, little cms.

In 2005, that story started to change a bit – the GIMP started conserving ICC profiles in JPEG files and allowing the user to see the list of ICC profiles with the 2.3.2 release, in July 2005. Scribus added support for soft proofing in version 1.2.3 in September 2005. Krita released version 1.5 with support for color profiles in December 2005.

In the first Libre Graphics Meeting, one of the most popular presentations was by Marti Maria of little cms, who gave an overview of what color management is, how ICC color profiles fit into the picture, and finally what applications need to do to integrate color management support. One of the outstanding memories I have from the conference was Carl Worth of Cairo being very excited about the conference, and in particular about meeting Marti.

Since 2005, things have changed significantly.  Color management support has been completed for the GIMP in 2.4.0. Inkscape added support for ICC profiles in 0.44, in June 2006, soon after the first Libre Graphics Meeting in Lyon, and this support has been further improved in the recent 0.46 release.

And since, color management has become almost ubiquitous – via the “ICC profiles in X” spec, all applications who support the spec (including, at last count, the GIMP, Eye of GNOME, Krita, UFRaw and Inkscape)  get soft proofing for your screen when X contains the ICC profile atom.

I’m not so presumptuous as to attribute the advent of color management to the Libre Graphics Meeting, but at least in the case of Inkscape, the work started at the conference. And for other developments, the bridges built and conversations started during LGM and other similar conferences has played a significant part in improving the state of affairs.