[ 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.