[ For the record, I am speaking for myself and not for Ubuntu, Debian-NP, Debian, or anyone else. ]
I have a vision for Debian; rather, I have a number of (sometimes contradictory) visions. One idea that I’ve fussed a lot about over the last couple years is Custom Debian Distributions. I have helped make a few things happen in one little corner of the CDD world (Debian-Nonprofit) but haven’t been as active as I’d like in the general CDD framework yet except through advocacy.
The idea behind a Custom Debian Distribution is, to borrow Enrico Zini’s terminology, to be global and local at the same time: to create an OS and set of applications that is targeted to a specific group of people and to contribute and collaborate within a larger community in a way that lets people without interest in that niche group benefit and for you to benefit from the work of people without interest in that niche. This is basically what Bdale Garbee talked about when he was talking about flavors in his 2003 DPL platform. I suspect people are hanging on to their one-flavor-fits-all model because they haven’t seen a compelling implementation of an alternative. I think that its the job of those of us that are sold on the idea to give them one (Thanks to everyone that has and continues to work on this in the CDD community).
Now as a few people know, I’m complicit in this whole Ubuntu Conspiracy. When Mark Shuttleworth first approached me about the project, the first thing I thought about was Custom Debian Distributions. I wasn’t, and am still, not exactly sure how those things relate exactly.
I was (and continue to be) tempted to think of a spectrum of "Debianness" with officially blessed Debian releases at the center, testing and unstable slightly outside of that, CDDs farther outside but just within the circle of what’s "officially" Debian, Ubuntu beyond that trying its best to hug the line, LinEx y sus hermanas in there somewhere, and Lindows almost on the periphery of our vision denying — to some but not all — that its on the spectrum at all.
But it’s not that simple.
From a technical perspective, it’s manageable. Ignoring project affiliation and institutional relationships, we might say that CDDs are about creating and maintaining a derived version of Debian over time and in way that offers all changes back to the pool of Debian (Debian won’t take all). Forking in the traditional sense is one thing — and it’s relatively easy; going out of your way to share and collaborate within the Debian community is one way to define a CDD.
So it’s simple if we, for the moment, think of Debian as a single monolithic blob — forget subprojects and CDDs. We can break the goals of a any Debian derivation down into three basic types of customization:
- Package selection: Which software in Debian does the deriver want to include?
- Package configuration: What configuration changes does a deriver want to include (anything you can do with debconf/cfengine)?
- Package replacement (for lack of a better term): What packages does a derivative want to ship that has diverged from the package in Debian in terms of code (bug fixes, features, whatever)?
The problem (for my simplified model for explaining Debian derivatives — I don’t think it’s a problem in general) is that some people are working within this framework in ways that are visibly connected to the Debian community and some people are not and don’t want to be. Basically, Debian is whole lot more complex than just a ball of code.
In Jeff Licquia’s blog, he mentioned that Ubuntu is a fork. In a way he’s correct and in a way he’s not. I think part of the problem is that "Debian" refers to a long list of things. Just to start we’ve got:
- Debian: the group of volunteers;
- Debian: the "project" with a Constitution, leader, and decision making structure;
- Debian: the ball of code (But which ball of code? Stuff on Alioth? Stuff in contrib? Stuff in the Debian-NP archive?);
- Debian: the infrastructure that runs the code together;
- Debian: the shared goals and the action of sharing (you share within the Debian community — you are part of Debian);
This creates problems and uncertainty that we in the CDD community has been grappling with for a long time: Is Debian-Nonprofit Debian? Can any CDD really be Debian?
Of course, coming from the Debian community, the CDD community began with the answer ("yes") and then went about trying to create and argue a justification. We’ve even defined the technology based on what would or would not allow us to honestly call ourselves "Debian" and have attempted to grasp onto definitions of "Debian" that make that possible. Debian-NP and every CDD is still trying to figure out what it means to be Debian and Debian-NP at the same time — how does one strike that balance?
Ubuntu starts out with an answer as well. Ubuntu is not Debian and I suspect this is what Jeff was referring to. Ubuntu wants to do things that Debian can’t, won’t, or just isn’t all that good at and thare is great room for synthesis here.
My concern is that the political side of things — the "who is Debian and who is not" — risks driving a wedge between the technologies being used by those customizing Debian from the inside and from the outside. People don’t work together because they are "not part of the same project" when they have every technical and strategic reason to collaborate.
Basically, I think we should let Debian stand for something political: an organization. When it comes to code, I think we should forget about this and find creative ways to work together.
I want to see Ubuntu, Progeny and the other Debian derivers work closely with the Debian derivers within Debian. I want this work to lead to systems of common infrastructure that makes applying the the different types of customization something resembling a standard. That’s only going to happen if we all try. That doesn’t mean there will be One True Way — there won’t. It does means that everyone is going to have to be flexible. I think ultimately, it will be worth it.