Mark Shuttleworth's Linuxcon keynote has gotten a lot of attention. Some for being the big Linux celebrity, some for making some unfortunate comments, and a small bit for his actual message. I'm going to report on his actual message because it is visionary and important.
I recommend that anyone who is serious about devoting their time and talents to Linux/FOSS, in whatever capacity-- coder, designer, artist, documenter, translator, advocate, whatever-- watch this talk for yourself. Thanks to the generosity of Linux Pro Magazine and the Linux Foundation it is available online. You can also download it for local streaming: $ wget http://techcast.com/events/linuxcon/shuttleworth/shuttleworth.flv
Cadence, Quality, Design
Mr. Shuttleworth's three points are Cadence, Quality, Design, and they are all part of coordinated vision for the future of Linux development. It is a very different vision from how it's done now. The current state is very developer-centric. Software developers start and maintain projects, and the quality, responsiveness, and direction of projects are mainly controlled by the developers. Mark's vision is broader and more ambitious:
"People often ask me why I'm so fascinated by Free software , and why I put so much time, energy, and money into Ubuntu...I really believe the Free software process is the right way to build software. Not only that, but there is the potential, if we raise our game... that we could end up defining the experience that the average person has whenever they turn on a computer."
Ok, sounds good, so how do we get there? Cadence, the popular new buzzword, is about the value of timed releases:
"The release itself is enormously energizing...the release is the beginning of the journey for many other parts of the community and for our users. When you make a release it has all sorts of other benefits. It broadens the base of people who can participate...think of all the other people in the community who want to be helping you get your software out to the world: documenters, translators, artists, advocates...their job begins once you commit to making a release.
"It also generates a tremendous amount of testing...for every one person who is running a development version of Ubuntu, there will be ten people who download and try and work with the beta release. And then there will be a hundred people who actually use the final release...Short interations, shorter cycles mean more testing. They also mean better prioritization and planning...if you give yourself a shorter amount of time you say to yourself "What are the most important things for us to get done?
"A release brings publicity...we're doing amazing stuff. A release is an opportunity to get out there and talk about that..it brings more contributors, participants, users."
He used the example of a Web development team that has a monthly release cycle. The Linux kernel is on a three-month release cycle "which is magical...it is energizing." Gnome and KDE are on six-month cycles.
Cadence is also about coordinating with upstream and other projects. There is some progress in coordinating the next Ubuntu LTS release so that it will have the same base kernel and other key base packages as Debian. They're not quite holding hands and singing songs yet, but it's a start. He thinks that coordinating major releases will make life easier for users and distribution maintainers because there won't be so many different package versions floating around, and it will reduce the perennial conflict of who is responsible for a particular bug. (Users love reporting bugs only to be told 'Not our problem, report it to upstream/downstream/sidewaystream/anyone but us')
It will also help developers by reducing the numbers of distros to try to support, and enabling better collaboration and planning.
Quality
This is a potentially sticky subject to address because FOSS development is open and personal. The developer's name and code are there for all to see. Which theoretically leads to better software because devs are more accountable, have more reason to take pride in their work, and anyone (theoretically) can contribute.
He thinks that test plans and automated testing are good tools for quality control, and says there is a clear difference between projects that use them and projects that don't. Another benefit is opening doors to new developers:
"...a lot of upstream projects take the form of a couple of guys who know each other really well...it's really hard to cross the chasm from being somebody who is interested, and shows up and wants to talk about it, and maybe has some code to contribute, versus getting to the point where you're one of those guys...
"Maybe for some people it's part of the fun, you have this cabal effect. But I think it's hugely damaging to our ability to grow projects. Only people who are insanely persistent can cross that chasm. Whereas if you're more open to code that's coming in from people you don't know then it's really exciting for those guys, they get to contribute code...and it energizes them to do more."
Automated testing reduces conflicts and saves face because "You can't argue with the robot." It finds problems without pointing fingers.
Code review improves code quality and is another mechanism for bringing new developers on board, and there are programs for remote collaboration so they don't have to be in the same physical location.
He goes into a bit of detail on source control management, automated processes, checkins and checkouts, having a stable trunk, and other nuts-and-bolts aspects of software project management.
Good Design = Moving Into the Big Leagues
Mark is big on design:
"If we really want to make a difference in this world, in the consumer world, we have to write software that can compete with the best-designed software out there....
"We have to figure out how to... deliver stuff that is usable, and consistent, and fits users' brains. We have to figure out how to start software development with a very strong view of design, of user expectations."
He thinks to achieve this that developers would benefit from working with professional designers and usability experts. This collaboration needs to start early, before difficulties are hard-coded into the program:
"APIs and middleware make a huge difference to what's possible in the user experience. Guys say "Look, I work in the kernel, I do device drivers, I don't have to worry about user experience." But decisions made in the kernel can have an enormous impact on what's possible in the user experience."
So he says we're great at making software for experts, but have some way to go for making it usable and accessible to non-experts. Being plagued with multiple wi-fi stacks is an example of problems and poor user experiences starting from the lowest level. (Thanks to John Linville and the rest of the wi-fi team we now have a shiny new integrated wi-fi stack that works beautifully for users and developers.)
"We have to think carefully about quality. The code may be high-quality, it may be rigorous and robust and handle exceptions and errors really beautifully...but is really quality if what you've done is made it almost impossible for the end user to have a good experience, if the end user wasn't sitting right next to you?"
He closed with an invitation for anyone who wants their software reviewed by professional designers.
Those are just the key points, and I think it is well worth listening to the whole talk a couple of times, because these are radical concepts for the the herd-of-cats world that is Linux/FOSS.
Unfortunate Comments
Several gaffes nearly spoiled this talk for me, and I shall never be able to hear the word "releases" again without feeling a bit nauseated. Free tip to speakers and keynoters: Include your whole audience when you talk to them, especially when one of the themes of your talk is collaboration, community, and expanding the contributor and user base. Avoid stupid jokes. Stick to the subject. Thank you.
For those who are curious, please refer to:
Mark Shuttleworth's Community Has No Women
On keynotes and apologies
Explaining to girls
Sexism Debate
Carla Schroder is the author of the Linux Cookbook and the Linux Networking Cookbook (O'Reilly Media), the upcoming "Building a Digital Recording Studio with Audacity" (NoStarch Press), a lifelong book lover, and the managing editor of LinuxPlanet and Linux Today.
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 comments:
Post a Comment