Notes from the Mousepad

Here’s a few pictures from UDS:

Saying goodbye to Matt Zimmerman at the UDS opening keynote. It took me until Friday to thank Matt for his advocacy around women’s issues, as well as LGBT and gender issues. There aren’t many people in positions such as his who do so, so many thanks, Matt. Best of luck to you.

Jani Monoses and and Charlie Kravetz, the past and present leaders of the Xubuntu project. (Missing in this photo is Cody Somerville, who headed up Xubuntu in between the two pictured here. Also missing is Lionel Le Folgoc, who was surely off packaging software somewhere in France.)

The hotel’s grand ballroom, with the one and only Micah Gersten (micahg) in the foreground. He makes us all feel more secure when he’s around.

The bridge on the Danube at night. We had a lot of fun walking around and taking pictures that night.

Me giving a thumbs-up to the trip while going down one of the super-escalators to the train platform. (Credit to Lyz Krumbach for this photo – CC by SA 3.0 ftw).

More pictures (some of them fuzzy!) can be found on my Picasa page. Many thanks to Canonical for sponsoring my airfare and accommodations on this trip.

Now that my week at the Ubuntu Developer Summit is over, and I have completed my safe flight back, I thought I would write up a blog post about my experience while I complete my recovery from jet lag.

My week at UDS was a challenging week. A great week. A week in which I had great discussions around docs, met lots of cool people, and wound up expanding the limits of what are normally considered acceptable sleep patterns.

I had three docs-team sessions during the week. I also attended two sessions about cloud-related documentation, and another session on server documentation. The three docs-team sessions focused on the team strategy, our goals for the 11.10 release cycle, and evaluating a web-based documentation platform.

Team Strategy

The inspiration for the team strategy discussion is the Xubuntu Strategy Document. Have you read it? When Cody Somerville first wrote it, part of me was like, “Are you serious? Did you write this yourself?” It seemed too complicated. In practice, though, I’ve seen the Xubuntu team reference that document while making decisions time and time again. I think a similar document would benefit the docs team, too. I’m preparing a draft document based off of recent team discussions, and will be sharing it in the next week.

Team Goals for the 11.10 Release

The team goals session was pretty great. People in the room, and people listening in via the audio casts, gave helpful input. There was more focus on the Ubuntu wiki at UDS than I anticipated. Some of our goals for this cycle include creating a strategy document, contributing to upstream docs projects, refactoring our team wiki, testing of documentation accessibility, testing a preferred help layout, doing stable release updates for docs and translations, squashing boogs, adopting a consistent coding style, updating our style guide (or picking an existing one), and doing some of the initial work in revamping help.ubuntu.com.

It sounds like a lot, and it is, but some of it is already a work in progress. We will make these goals explicit during our next team meeting.

Web-based Documentation Platform

The group behind this project is Pronovix, a Drupal consultancy. I knew that their project was using Drupal and DITA, but I wasn’t sure what *their project did*. They had some of their staff based in Hungary, just a short trip away from Budapest, so I thought it was worth getting in touch to learn more about their approach and how it might benefit us.

DITA stands for the Darwin Information Typing Architecture, an XML syntax developed by IBM that specializes in content profiling and content reuse. The advantage of content reuse with a tool like DITA is that it allows you to write something once, write it well, and reuse it most everywhere. That is the idea, at least. Implementation of DITA can be difficult. Their project has promise, but the toolchain isn’t currently packaged by any distro other than OpenSUSE. Harald Sitter (Mr. Apache Log File) felt that this very much limits the likelihood of upstream adoption.

Even with that in mind, we are going to seriously evaluate their platform. It was very considerate of this group to make a trip to demonstrate their project, and we want to be supportive of everyone who is working in open source documentation.

There are quite a few irons in our fire, and we’ll have to get word out about our activities somehow. Our progress will likely be presented via a new Ubuntu Documentation Team blog. We think now is a good time to start one up, so look for more info on that soon, as well.

Recently Mark Shuttleworth wrote about how Qt will become part of the Ubuntu 11.10 desktop, and that Qt-based apps will eventually be considered as possible default Ubuntu apps. Obviously, this would be a big change from using GTK-only applications (that is, aside from Firefox and Open/Libreoffice applications), but Mark encourages GNOME developers to consider using Qt, too. He writes, “Perhaps GNOME itself will embrace Qt, perhaps not, but if it does then our willingness to blaze this trail would be a contribution in leadership.”

I agree on this, and think that enabling usage of Qt in GNOME projects would be a contribution in leadership. It would be great if developers had the option of using tools like Qt Creator and Qt Quick when building applications for GNOME-based desktops (or other devices!).

The question is: How do you make that happen? All technical matters aside, how do you encourage GNOME developers to consider using Qt for their applications?

To me, one major consideration in further developing the Qt-to-GNOME bridge, and encouraging developers to use Qt in GNOME-based desktops, involves copyright. I think the GNOME project, and its large group of developers, would be more likely to embrace Qt if Canonical did not put the dconf binding work (or other such Qt/GNOME integration work) under strict Canonical ownership via their contributor agreement.

The issue is that the contributor agreement gives all copyrights of the work (even contributions made by non-Canonical employees) to Canonical, and permits Canonical to relicense the work (even make it proprietary) at their discretion. To me, this would present a considerable risk for the GNOME developers and for the GNOME project.

The folks at Canonical have not yet indicated whether or not the contributor agreement applies, or will apply, to the early QT/dconf binding work. My thinking is that, if Canonical is disinclined to having the larger GNOME project use Qt, Canonical will request full copyright ownership of any Qt/dconf work. Thus, Canonical would “own the bridge” between the land of Qt and the land of GNOME, and anyone who wants to use that bridge would have to do so knowing that it could eventually be made proprietary.

Moreover, I think it would be a bit ironic if Canonical put the Qt/dconf work under their contributor agreement. As I understand it, Canonical’s main justification for requiring copyright assignment is that they “wrote the code,” for that project, and would like to maintain ownership of it. While folks at Canonical may have done the initial Qt/dconf bindings work, a primary reason that Canonical is even able to safely use Qt in their business is because Nokia opened up Qt, and removed the copyright assignment requirement from Qt contributions. Surely the Qt codebase, along with all of its associated tools, is much larger than any binding work (no matter how significant), so Canonical’s reasoning wouldn’t seem to be as applicable here.

However, if Mark and the rest of the folks at Canonical actually wants GNOME developers to embrace Qt on equal footing with GTK, they will either donate out the Qt/GNOME integration work to the larger GNOME community, or they will push the integration work upstream to Qt.

I’m hopeful that the folks at Canonical will choose either of the latter two options and make their initial Qt/Gnome integration work available under the same copyright-free terms that Qt has been made available to them. I agree with Mark when he writes, “it’s the values which are important, and the toolkit is only a means to that end.” While it may ruffle some feathers initially, having Qt as a viable option for development in GNOME-based desktops can only improve the free software ecosystem by giving developers more choices in the tools that they are able to use.

As a closing note, some of what I’ve written here is speculation and opinion, but if I’ve misunderstood anything, or if anyone can shed further light on this topic, please share a note in the comments.