Our first milestone
The goal of our first project, nicknamed ancient-patches, was to clear out an old batch of a few hundred Ubuntu patches whose status was unclear. We couldn’t tell which ones had been merged into Debian, which were waiting in the BTS, and which had yet to be submitted to Debian. All of them were several years old.
I’m pleased to announce that this project is now complete. Thanks to help from David Paleino, Colin Watson, Nathan Handler and Steve Langasek, we were able to clear over 95% of the patches in a matter of days. These were the easy ones: patches which were obsolete, or had already been applied. We discussed the remainder, and resolved all of the patches whose status was still unclear. This left the harder ones: patches stalled in the BTS, and patches where there was no consensus about what to do with them.
One of the stalled patches was merged into Debian via an NMU, eliminating the delta between Debian and Ubuntu. Another had been submitted to Debian by a third party, but was no longer shipping in Ubuntu, so we considered it obsolete for purposes of this project.
This has left only two patches out of the original list of 277. Both of them are filed in the BTS and have been discussed with the relevant maintainer team. One of them is expected to be obsoleted when a new upstream version is packaged, which implements similar functionality. The other is being discussed with the upstream developers, but there is no conclusion yet about whether it can be merged upstream or in Debian.
Although we weren’t quite able to clear the whole list, we still consider the project to be a success because:
- We ensured that all of the patches received due consideration for inclusion in Debian
- We proved the concept of DEX, with developers from Debian and derivatives cooperating on a common goal and sharing tools
- Most importantly, we learned from the experience
In the most recent DEX update on debian-derivatives, I highlighted a few important events for DEX:
- Our second major project, nicknamed “big-merges”, will begin soon. Our goal is to identify the few packages which are most diverged between Debian and Ubuntu, and work to get them as close to identical as possible. If you have suggestions for packages to focus on, let us know!
- Allison Randal is beginning a DEX project to implement the Python 2.7 transition across Debian and Ubuntu
- Nathan Handler is working on a Summer of Code project to develop specialized tools to help with this kind of cross-distribution teamwork
- Zack is organizing a derivatives BoF at DebConf 11
We’re looking forward to seeing DEX develop further. If you’d like to get involved, come and join us on the debian-derivatives mailing list or IRC (#debian-derivatives on
Matt Zimmerman and Stefano Zacchiroli
This June, soon after my seventh anniversary with Canonical, I will finish my job as Ubuntu CTO at Canonical. You can read my official announcement on the Canonical blog.
It’s sometimes hard to believe that it’s been that long since we first envisioned a Linux desktop “for human beings”. When I look at how far we’ve come, at the difference we’ve made to so many people, it’s easy to see how the time passed so quickly.
It’s been an incredible experience for me to play a part in building Ubuntu and Canonical. Whether building a decentralized company of hundreds of people, to a global community project of tens of thousands of members, I’m grateful for all of the learning opportunities along the way. It has been a privilege to work with so many brilliant, passionate and thoughtful people under such auspicious circumstances. There is much I will miss, and I have many memories to enjoy, from all-night global hacking sessions driving toward a ship date, to casual singing and playing music at our many face-to-face events
Nonetheless, it is time for me to seek out new challenges and stretch myself in new ways. I’ll be moving back to the US, closer to old friends and family, and starting a new job with a different type of company. I am leaving behind a capable and dedicated team at Canonical, who I am confident will achieve even greater things in the years to come.
I will remain active in the free software community as a volunteer. I intend to continue to participate in Ubuntu, and to serve on the Technical Board. I will also be continuing my work with Debian and the DEX project. This year, I’ve accepted advisory positions with the Ada Initiative and the Freedom Box Foundation, and will continue to support those organizations and their missions.
I’ll be in Budapest at the Ubuntu Developer Summit for the next week, and look forward to seeing my friends in Canonical and the Ubuntu community.
I’ll have more to say soon about what I’ll be doing next professionally. Watch this space for updates!
Since I resumed active status in Debian, I’ve been thinking about how to bridge the gap between Debian and its derivatives*. I’ve spoken at length with Zack, the attendees of the Derivatives BoF at DebConf 10, and the fine folks at the Derivatives Front Desk about the technical and social issues affecting derivative projects, and could probably write a very thorough series of blog posts on the subject.
Instead, Zack and I decided to try doing something about it: we have begun a project to test out a new approach to the problem.
DEX is all about action: merging patches, fixing bugs, crunching data, whatever is necessary to get changes from derivatives into Debian proper. DEX doesn’t try to change the way any existing project works, but adds a “fast path” for getting code from one place to another.
DEX is a joint task force where developers from Debian and its derivatives work together on this common goal. As a pilot project, we’ve established an Ubuntu DEX Team focused on merging code from Ubuntu into Debian. With members from both projects, we hope to be able to resolve blockage anywhere in the pipeline. Whatever needs to get done in order to merge an Ubuntu patch, someone in the Ubuntu DEX team will know what to do. If we get good results with Ubuntu, we hope that other derivatives will follow. With thanks to David Paleino, we’re excited that the Utnubu project is merging into DEX as it aligns well with their goals. I’m very grateful to have Colin Watson and James Westby signed up to contribute as well.
Our first project is simple: turn this list green. This is an archive of quite old patches from Ubuntu, most of which have probably been merged already or made obsolete, but they pre-date any kind of tracking system so they need to be verified. Once that’s done, we’ll move on to a new project with a new todo list.
If you want to see Debian benefit from technical work done in derivatives, DEX is a chance for you to act together to make it happen. If you work on a derivative and want to carry a smaller delta, come and join us. I’m sure we’ll learn a lot from this experience.
* There are many instances of great cooperation between Debian and derivative distributions, including joint package maintenance teams, and some derivatives are even part of the Debian project. Nonetheless, there are areas were most people I’ve spoken to agree that we need to do better. This is what I’ve referred to as the “gap”.
In the software community, people hold strong opinions on the subject of listening to users. Some feel that users are an essential source of information for making successful products, as evidenced in the customer development methodology, and seek to involve users deeply in product development. Others believe that users don’t know what they want, invoking the quote attributed to Henry Ford, “If I’d asked customers what they wanted, they would have said ‘a faster horse'”. Some say that user needs are unknowable except through the lens of a marketplace, where people choose in aggregate which products suit them best, and customers “vote with their wallets” (anything else is “anecdata”).
Regular readers will not be surprised that I believe they are all right, but only in certain contexts. The right strategy for involving users in product decisions will depend on factors related to the product itself, the market, and the product development method being used.
One of the most important is the life cycle stage of the product: is it a new and rapidly evolving concept, or a mature commodity, or somewhere in between? Simon Wardley explains this well over on his blog, so I won’t rehash his points here, but will add a few of my own.
If what we’re looking for is inspiration for a new product, it’s here that Henry Ford was right: users generally won’t hand you a complete product vision on a silver platter. They’ll frame their input in terms of what they know, and the choices already available to them. However, this doesn’t mean that users don’t have a role to play in this instance: watching users can be a great source of inspiration. It’s the combination of domain knowledge and passionate imagination which triggers the creative spark. Henry Ford applied his engineer’s interests to a problem which was evident all around him.
If our goal is to test whether a new product is a good fit for its users, there is no substitute for user feedback. We can guess at whether there is a fit, and our intuition may be good, but users are the ultimate judges, and we don’t know if we’re right or wrong until users evaluate it. So ask them! By engaging in dialogue with individual users, we can learn unexpected things which will help to refine the idea. If we don’t find what they think until our new product is released, we risk making something that no one wants. Why wait until it’s too late? It can be challenging to extract useful feedback for a product which doesn’t yet exist, but this effort is well worth it to avoid wasting much more effort in software engineering.
When our objective is to incrementally improve an existing product, individual anecdotes can mislead us. A given change may be an improvement for one user, but a disaster for another. What we want to know is whether the new version is better for the population as a whole, and in this case, we do well to rely on data. There are pitfalls here as well, of course. We need to choose our questions carefully, and realize that users will often resist any change: not because they’re stodgy by nature, but because they have to invest effort in adapting to the change. I think of incremental improvement as a joint investment made between product developers and their users, to improve the whole system of people and technology for the better.
By choosing the right tool for the job, we can make better decisions, improve faster, and ultimately solve the right problem for our users.
The Ubuntu website states that “we aim to make Ubuntu a wonderful place to participate”. We developed the Ubuntu Code of Conduct to set a standard for participants to accept each other in the spirit of cooperation, and have improved it over time to state these principles more clearly.
It is implicit in our philosophy that these and other Ubuntu values should hold equally true for everyone. I would like to propose that we upgrade this to an explicit statement on behalf of the project.
I have spoken with many people who were interested in joining a free software project, but were put off because they felt unwelcome. I know various people who participate in Ubuntu today, but sometimes face difficult social obstacles in order to do so. Going forward, I would like for us, as members of the Ubuntu community, to make the extra effort to accept all kinds of people. This may sound simple, but it can be very difficult to put into practice. People often don’t even notice they’ve gotten it wrong, until the offended party points it out to them. We need tools and guidance to make this a reality.
To that end, I would like to propose a diversity statement for Ubuntu. This draft has already received support from a majority of the Community Council, but I’d like to take it a step further. Because I want this to be a commitment that we can all stand behind, I’m also calling for support from the community as a whole. Please give this issue your consideration, and let me know in the comments if you can get on board with an official statement like this. The more support we have, the more real this commitment can be.
Here’s the text. Many thanks to Mary Gardiner, Valerie Aurora and Benjamin Mako Hill for their review and input.
The Ubuntu project welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining. Although we may not be able to satisfy everyone, we will always work to treat everyone well.
Standards for behavior in the Ubuntu community are detailed in the Code of Conduct and Leadership Code of Conduct. We expect participants in our community to meet these standards in all their interactions and to help others to do so as well.
Whenever any participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong.
Although this list cannot be exhaustive, we explicitly honor diversity in age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socio-economic status, subculture, and technical ability.
A couple of months ago, Debian project membership voted, after extensive discussion, to implement a fundamental change in the Debian community: to welcome as members people who make a valuable contribution to the project, even if they are contributing something other than source code.
This was a tremendous milestone for Debian, and one which made me feel proud to have been a part of the project. Historically, only developers had been eligible for membership, including voting and other formal privileges. Although other kinds of contributions were welcome, this disparity gave the impression that they were less valued than code contributions. It seemed to me at the time that Debian’s mission was to package all of the free software in the world, and if one’s efforts didn’t go directly to improving packages, they just weren’t as important.
I don’t remember when I first installed Debian, but I made my first contributions to the project in 1999, and officially joined as a developer in 2000. After several fun and rewarding years of packaging and development, I started a very demanding day job, and spent more and more of my energy into that, and less and less coding for Debian as a volunteer. However, my job with Canonical involved working with Debian, and that was a primary reason why it was interesting to me. It was an opportunity to introduce a whole new population of people to the things I loved about Debian.
The reality, of course, was more complicated. Following the launch in 2004, Ubuntu grew quickly in popularity and scope, diverged from Debian in significant ways, and relations between Debian and Ubuntu became strained. Canonical grew quickly as well, and the combination of a growing community, a growing company and growing user adoption was a challenge for everyone concerned. As a Canonical manager and a Debian developer, I felt the strain as much as anyone.
Meanwhile, and I felt more and more alienated from Debian. Debian developers who had been friendly in the past became suspicious of Ubuntu—and me—and I quickly became an outsider. My code contributions to Debian continued to decline, and I was no longer maintaining any packages. In Debian at the time, that meant that I didn’t exist. I saw it as an important part of my job to work with my counterparts in Debian, in a coordinating role, but found this increasingly impractical. In 2007, I received an inquiry from the Debian Account Manager, who had noticed I wasn’t actively involved in packaging, and wished to disable my account for security reasons if I wasn’t using it. Although I wanted to remain active in the Debian community, I had to agree that it wasn’t good security practice for me to hold onto my developer privileges. I relinquished my upload rights, with the option to come back if I resumed my development work, and officially became a nobody: I lost the right to vote, my email address and mailing list subscriptions, and all other official ties with Debian, except for the record of my GPG key in a special “emeritus” keyring for informational purposes.
Last month, Enrico Zini announced instructions for contributors to apply for membership under the new guidelines, which recognize many kinds of contributions, not only code. Today, after a three year hiatus, I am proud to be the first Debian member to be accepted through this new process. I expect to continue to submit the occasional patch, but my primary interest is in healing the rift which still exists between Debian and Ubuntu by contributing in a more personal way. Please feel free to contact me if you’d like to work together on this. You can reach me as mdz at either debian.org or ubuntu.com, or on IRC.
I would like to thank Stefano Zacchiroli, for proposing the General Resolution which enabled Debian to make this transition, and for all of his other work as Debian Project Leader to help Debian grow and improve. I also appreciate Enrico Zini, Jonathan McDowell and Martin Zobel-Helas for expediently processing me and working through the technical changes needed to implement the resolution correctly.
It’s good to be back.