LWN.net Logo

Leading items

OLS: Shuttleworth on free software development

By Jake Edge
July 30, 2008

In the third keynote given at this year's Ottawa Linux Symposium (OLS), Mark Shuttleworth spoke about "The Joy of Synchronicity". In his speech, he discussed his idea of synchronizing releases between major distributions but he also advocated time-based, rather than feature-based, releases for free software in general. He believes that a release has value in and of itself; by doing them on a regular schedule, a project will get into a kind of cadence that is useful for both developers, testers, and users.

Before starting, Shuttleworth was subjected to the traditional introduction by the previous year's keynote speaker—James Bottomley, in this case. Bottomley looked at Shuttleworth's postings to newsgroups over the years, noting three year-long valleys in the graph where there were no postings. It turns out these corresponded to events in Shuttleworth's life. The first is when he received a substantial amount for selling Thawte to Verisign: "when someone is being productive on the mailing list, never give them half a billion dollars," Bottomley said. For the second, he has a pretty good excuse as he was not on planet earth; the last corresponds to starting Ubuntu.

In a nod to Bottomley and the other kernel hackers, Shuttleworth mentioned that he had been working on his slides up until close to the start of his speech, while doing some unrelated things in the background—like updating his system. That picked up a new kernel as well and he did a suspend to RAM when he was done; only later in the cab ride to the Congress Centre did he think: "maybe that was a mistake". It turned out to work just fine, which is a testament to both the kernel and to distribution update mechanisms.

The alliterative theme of the speech was that free software development should be guided by "cadence, collaboration, and customers". The cadence is a regular schedule for releases, similar to what GNOME—who pioneered this technique, according to Shuttleworth—and the Linux kernel do. This gets a project into a rhythm that makes it more predictable, which enables all interested people to schedule themselves around it. He compared this to various development methodologies such as "Agile" and "Lean".

Industries are governed by rules, so if you want to change an industry, you "have to find which rules are only in our heads". Cross-project collaboration is one of those rules. "Nowhere is it written that projects can't collaborate." It is harder to do that if each distribution is working with different versions of the various base-level tools: the kernel, X.org, GNOME/KDE, OpenOffice.org, Mozilla, and so on.

Shuttleworth contends that it is releases, rather than features, that bring attention to Linux. In answer to critics who believe that distributions should compete with each other, he says that is just "an opportunity to create friction." Free software companies don't compete on versions, but rather on philosophies and what things they focus on. He likens it to food courts or automobile sales malls where there are many choices in one location which serves to increase the sales of all.

For major transitions, Shuttleworth is a fan of establishing meta-cycles, the idea that every N releases is a major release, which may result in breaking some backwards compatibility or introducing completely new functionality, along the lines of KDE 4 or GNOME 3.0. As an example, he used a six month release cycle where every fourth or sixth was a major release. For a distribution, that might be a long-term support release, rather than a major change.

One of the key requirements that Shuttleworth sees is the need to "keep the trunk pristine", by doing integration on the trunk and feature development on branches. Along with this is the need for more and better tests. While not necessarily believing in test-driven development, he certainly leans that way. In any case, all the tests should pass before committing to the trunk.

Many projects do not yet have an extensive test suite, but this needs to change. He quoted a Chinese proverb that "the best time to plant a tree is 20 years ago, the second best time is today". He mentioned that he is working on a robot that controls the trunk of a development tree. Developers will request it to merge from a branch, so the robot merges the branch and runs all the tests. If the tests pass, it commits, otherwise it gets kicked back to the developer.

He sees distributions as "an effective conduit of upstream to users," to that end he believes that agreeing on versions of vital infrastructure can only help. Bugs that users find will be more likely to be fixed; those versions will also get better testing which will help developers. It is a conversation that free software should be having because it is a "very exciting idea" that won't work for every project but should be attempted and experimented with.

In answer to criticism about Ubuntu not contributing as much as other distributions would in his proposed synchronized release, Shuttleworth was adamant that it was not true. He hates to see the antagonism and vitriol between distributions. "We have much bigger fish to fry and they are probably not here today."

If all of the distributions were to standardize on a particular version of some project for their next release, what happens if that project falls behind? There are risks associated with that, Shuttleworth admits, but if it were happening, more resources would be available to help the project catch up. In the worst case, perhaps falling back to the previous version would have to happen. "Being tightly coupled has risks."

This is clearly an idea that Shuttleworth feels strongly about, not necessarily that it be adopted fully, but that it be discussed and considered. Certainly some of his ideas have a great deal of merit. We will have to wait and see whether the grander vision will ever be implemented.

Comments (24 posted)

Harald Welte on his new role with VIA

By Jake Edge
July 29, 2008

Hiring a well-known free software advocate to oversee efforts to work with the community is a good plan for any company, but for a company that has had rocky community relations, it may be essential. VIA Technologies has done just that, by contracting with Harald Welte to help guide its strategy to work more closely—and less contentiously—with the community. VIA announced a new effort aimed at cooperation with the free software world last April, but got off to a slow start that had people wondering about its commitment to fulfilling that promise. Welte will be well placed to ensure that community concerns are heard within VIA.

[Harald
Welte]

Highly visible in the community for his work on things like netfilter/iptables and, more recently, the Openmoko phone, Welte has the skills to provide VIA with excellent advice. He has also won several awards for his work on GPL enforcement as founder and driving force behind the gpl-violations.org project. We caught up with Welte at this year's Ottawa Linux Symposium to discuss his new role.

Because of his work on Openmoko, Welte had been traveling frequently to Taiwan, making a number of industry contacts amongst the companies located in Taiwan. About nine months ago, he was "invited to talk to VIA and give them some feedback from the community". The company, he says, knew from the beginning it needed community input, but how to get that was not decided until late May or early June, when they asked Welte provide it on a regular basis.

The push from within VIA came from management, specifically product management, which is somewhat surprising—in the US and Europe, at least, it is typically engineering that pushes for better community relations. "It's a really big opportunity for me being a representative of the community to talk to a company at this high of a level. That's what makes me very optimistic."

It's a really big opportunity for me being a representative of the community to talk to a company at this high of a level. That's what makes me very optimistic.

VIA primarily needs to get drivers and other software for their graphics hardware cleaned up and submitted upstream. It is not just the X.org drivers for 2D and 3D graphics that need to be mainlined, there are also DRM and DRI patches that are maintained out-of-tree. He wants to see kernel patches get moved upstream to kernel.org, while X patches get merged into X.org code. A free 2D driver supporting most VIA chips, old and new, will be available soon.

Welte sees his role as "focusing more on the open source strategy inside VIA". That includes improving the skills of VIA's R&D group so that they produce drivers that are mainline quality. Various kinds of problems exist in the drivers, the coding style may not meet the kernel requirements or they may not use the proper APIs. Currently, drivers exist for new products that are supposed to ship with mainline drivers available; Welte will help ensure that happens. "I perceive myself as community person rather than a VIA person."

He points to Intel as a "shining star" example of supporting free and open source software, though "sometimes they might focus a bit too much on drivers than on open documentation," especially for wireless hardware. One of the areas that VIA is working on is open documentation for its hardware, but Welte isn't sure when those will be released—though some 800 pages were released this week. Schedules are largely out of his control, as they are subject to a wide variety of variables within VIA.

His role with VIA is a chance to "really make a silicon manufacturer understand how the open source community works and what the benefits are to working with it". He will be traveling back and forth from his home in Berlin quite a bit; "that's good, I love Taipei". He has also started to learn to speak Chinese.

It seems like a great fit that, in some ways, Dave Jones predicted in his blog posting linked above: "I'm beginning to think the only way VIA will ever really 'get it together' is if they employed someone from the Linux community who actually understands how all this works, because it seems someone in Taiwan isn't getting the memos." Perhaps a little late, but it seems that VIA has gotten and understood the memos now.

Comments (5 posted)

Interview: Kristen Carlson Accardi

July 24, 2008

This article was contributed by Valerie Henson

Kristen Carlson Accardi is a Linux kernel developer for Intel's Open Source Technology Group. She is the maintainer for the PCIE hot-plug driver, the SHPC hot-plug driver, and the PCI hot-plug subsystem in the Linux kernel. She is currently working on SATA drivers, including implementing power management features.

Kristen is the benevolent dictator for the upcoming Linux Plumbers Conference. We interviewed her about LPC, why so many Linux developers live near Portland, Oregon, and life as a kernel developer.

What is Linux Plumbers Conf? And why the "Plumbers" part?

Linux Plumbers Conference is a conference for developers working on the low level programming of Linux, including kernel, libraries, and system applications such as udev, hal, and dbus. We came up with the name "Plumbers" because we wanted to represent these areas as basic system infrastructure which has many connections. Plus these programs are sort of the nasty, grimy, unglamorous underbelly of the system - not unlike the pipes in your house. Essential - but nobody wants to know they are there and everyone takes them for granted until they don't work.

Running a conference is a lot of work in addition to your full time job as a Linux kernel developer. What made you decide to start Linux Plumbers Conf?

Actually, it was the idea of a group of people. The Portland Linux kernel community gets together once a month or so to socialize and drink beer. At one of these gatherings we had a conversation about how difficult it was to solve big picture problems that cross multiple project boundaries. We felt that there are some cases where you really need to be able to just get everyone in a room and be able hash things out in person, but there wasn't really a forum for this. Existing conferences were either too narrow (like Kernel Summit or the X developers summit) or too broad for our purposes.

Then someone said something like "Hey, why don't we just make our own conference". Because we are nothing more than a group of developers with a shared love of beer, we went to the Linux Foundation and asked them to collaborate with us, and it's been a wonderful partnership. It's definitely been a challenge for a bunch of software engineers to try and organize a conference, but we've leaned heavily on LF for advice and we've learned a lot in the past year.

Most conferences are centered around talks in which speakers present their work, but open source developers often skip the talks so they can discuss ongoing projects face-to-face. How is LPC balancing these needs?

Our format for the conference is based on the idea that we would have a bunch of "microconferences". Each microconf is meant to represent a topic that should be small enough to be able to adequately discuss in a few hours, and should preferably span multiple project areas. Each microconf is being organized by a single expert in the area who dictates the content of the microconf. The microconf runner may decide to have a couple talks and an hour or so for discussion, or they may decide to split the group into teams and solve some specific problems. We are leaving this up to the microconf runner to decide, although we are recommending that talks be not more than 25 minutes in length so that there is ample time for discussion and questions.

We also have a general track for presentations that do not fall under our predefined MC topics. In addition to the rooms for the microconfs, we have several rooms that are going to be available for "unconference" style talks. People wishing to get together in smaller groups will be able to reserve a room at the beginning of the conference. Our larger rooms will also be available in the afternoon for working sessions.

For several years, developers have been organizing individual summits and workshops for particular projects, like networking and file systems. LPC microconfs are similar, but they're held all in the same location and time. Why did you want to put the microconfs together into one conference?

We did this to encourage cross project communication. Individual summits are great for solving narrow problems, but they tend to compartmentalize developers from each other.

Who is organizing and sponsoring LPC?

LPC is organized by a group of volunteers from the Portland Linux development community and is underwritten by the Linux Foundation. We are a group of developers who just wanted to attend a conference which didn't happen to exist yet, so we made our own. Because we are all volunteers, we have very little overhead for this conference, and the money our sponsors have given up is being used directly on making the conference as productive and memorable as we can make it, with hopefully a little left over to start over again next year. Our Platinum level sponsors are Intel and IBM, with NetApp sponsoring at the Gold level, and HP, MontaVista, and Google at the Silver. In addition the Linux Foundation and Portland State University and have given us so much more than money - they have been true collaborators and we are so grateful for all their time and effort.

Were there any sponsorships you didn't accept?

Not that I can recall - we actually started fund raising a little late and missed a lot of people's planning cycles. We were extremely lucky that there were so many great sponsors like Intel, IBM, NetApp, HP and Google that believed our conference was valuable enough to find the money in their budget despite the short notice.

How did you decide on the location of LPC?

Portland State University was always our first choice for LPC. We wanted a non-corporate, friendly environment that was downtown. It was very important to us as well to have a "green" conference - hey, we are Oregonians! We wanted a place were there were plenty of hotels and restaurants within walking distance so that people would not have to rent a car. In addition, we didn't want the more traditional convention center or hotel atmosphere, nor could we afford it.

Tell us more about LPC as a green conference.

As frequent conference-goers, we are all a little dismayed by the waste generated from conferences. Disposable drinking cups and bottled water, flyers and schwag that immediately hits the garbage bin when you get back to your hotel, and driving around from event to hotel and back again are just some of the things that we decided we'd like to not have at our conference. As such, we are not distributing printed material at the conference. We're also limiting our schwag to only things we've deemed useful, and we are working with our caterers to reduce paper waste and provide foods from local, sustainable sources where possible.

How did you get started in Linux kernel development?

I started using Linux in college back in 1994 or 1995 - I wanted to be able to work on my homework at home rather than in the lab, and all we had in those days was a horrendously slow modem connection to the school. For years afterward, all I wanted to do for a living was to work on Linux, but it wasn't until around 1999 that I got my first chance to write some drivers for Linux while working in Intel's networking division. I had previously written device drivers for Netware - a job I'd gotten right out of college. After working on out-of-tree drivers for embedded systems and research projects for many years, I finally joined Intel's Open Source Technology Center in 2005 and was able to start contributing upstream in a meaningful way.

Portland is home to many top Linux developers, including Linus Torvalds. Why do you think Portland is so attractive to open source developers?

Honestly - I have no idea. People ask this question all the time, and all we can do is speculate. I know why a lot of us live here - it's a great city to live in. At some point you get enough critical mass of developers that you start attracting others. It could be any number of things. Maybe because it's easier to thumb our noses at Redmond from here?

In your opinion, what are some of the most important technical trends in Linux kernel development today?

Low power features in hardware is driving a lot of kernel development these days.

Tell us about some of the places you've traveled for your job.

When you work in open source, you have to travel to meet your "co-workers". I've had a chance to go to OLS a few times, Sydney for LCA a couple years ago, and Cambridge last year for Kernel Summit and LinuxConfEU. Recently I traveled to FISL in Porto Allegre, Brazil. I've also been to Ireland for Skycon - a fun and interesting conference. I'm actually looking forward to not having to travel to attend LPC.

Thanks, Kristen, for taking the time to answer our questions.

Comments (6 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds