Debian is a large, complex operating system, and a huge open source project. It's thirty years old now. To many people, some of its aspects are weird. Most such things have a good reason, but it can be hard to find out what it is. This is an attempt to answer some such questions, without being a detailed history of the project.

What Debian wants to be

Debian wants to be a high-quality, secure general purpose operating system that consists only of free and open source software that runs on most kinds of computers that are in active use in the world.

By general purpose I mean Debian should be suitable for most people for most purposes. There will always be situations where it's not suitable, for whatever reason, but it's a good goal to aim for. Some other distributions aim for specific purposes: a desktop, a server, playing games, doing scientific research, etc. It's fine to aim to be general purpose, or specific purpose, but the choice of goal leads to different decisions along the way.

For Debian, aiming to be general purpose means that Debian doesn't choose what to package based on the purpose of the software. The only real choice Debian makes here is on whether the software is free and whether it's plausible for Debian to maintain a high quality package.

The constitution, power structure, governance

Debian is one of the more explicitly democratic open source organizations. It has well-defined processes for making decisions, and elects a project leader every year. Further, the powers of the project leader are strictly constrained, and most powers usually associated with leadership are explicitly delegated to other people.

The historic background for this is that the first Debian project leaders were implicitly all-powerful dictators until they chose to step down. Then one project leader went too far, and a revolt threw them out, and democracy was introduced. As part of this, the project got a formal constitution, which defines rules for the project.

The reason Debian has the rules it has, is because less rules, and less bureaucracy, didn't work for Debian earlier in its history.

Social contract and Debian free software guidelines

In the mid-1990s, before the term open source had been introduced, what was "free software" was defined by the Free Software Foundation, but in a way that left much to be interpreted. Debian wanted to have clearer rules, and came up with the Debian Free Software Guidelines, and made them part of its Social Contract.

The social contract is Debian's promise to itself and to the world at large about what Debian is and does. The DFSG is part of that. This is a foundation document for Debian, and changing it is intentionally made difficult in the Debian constitution.

The more detailed rules have made it clearer what Debian will accept, and have simplified discussions about this. There is still a lot to discuss, of course.

The DFSG was later the basis of the Open Source Definition.

Self-contained

Debian insists on being self-contained. Anything that is packaged in Debian, by Debian, must be built (compiled) using only dependencies in Debian. Also, everything in Debian must be built by Debian. This can cause a lot of extra work. For example, current programming language tooling often assumes it can download dependencies from online repositories at build time, and that is not acceptable to Debian.

The main reason for this is that a dependency might not be available later. Debian has no control over third party package repositories, and if a package, or entire repository, goes away, it might be impossible for Debian to rebuild the package. Debian needs to rebuild to upgrade to a new compiler, to fix a security problem, to port to a new architecture, or just to make some change to the packaged software, including bug fixes.

If Debian weren't self-contained, it would be at the mercy of any of the tens of thousands of packages it has, and all their dependencies, being available when an urgent security fix needs to be released. This is not acceptable to Debian, and so Debian chooses to do the work of packaging all dependencies.

That means, of course, that for Debian to package something can be a lot of work.

No bundled libraries

Debian avoids using copies of libraries, or other dependencies, that are bundled with the software it packages. Many upstream projects find it easier to bundle or "vendor" dependencies, but for Debian, this means that there can be many copies of some popular libraries. When there is a need to fix a security or other severe problem in such a library, Debian would have to find all copies to fix them. This can be a lot of work, and if the security problem is urgent, it wastes valuable time to have to do that.

As an example: the zlib is used by a very large number of projects. By its nature, it needs to process data that may be constructed to exploit a vulnerability in the library. This has happened. At one point, Debian found dozens of bundled copies of zlib in its archive, and spent considerable effort making sure only the packaged version of zlib is used by packages in Debian.

Thus, Debian chooses to do the work up front, before it's urgent, while packaging the software, and make sure the package in Debian uses the version of the library packaged in Debian.

This is not always appreciated by upstream developers, who would prefer to only have to deal with the version of the library they bundle. That's the version they've verified their own software with. This sometimes leads to friction with Debian.

Membership process

Given the size and complexity of Debian as an operating system, and its popularity, the project needs to trust its members. This especially means trusting those who upload new packages. Because of technical limitations in Linux in the 1990s, every Debian package has full root access during its installation. In other words, every Debian developer can potentially become the root user on any machine running Debian. With tens of millions of machines running Debian, that is potentially a lot of power.

Debian vets its new members in various ways. Ideally, every new member has been part of the Debian development community sufficiently long that they are known to others, and they've built trust within the community.

The process can be quite frustrating to those wanting to join Debian, especially to someone used to a smaller open source project.

Release code names

Debian assigns a code name for its each major release. This was originally done to make mirroring the Debian package archive less costly.

In the mid-1990s, when Debian was getting close to making its 1.0 release, code names weren't used. Instead, the archive had a directory for each release, named after its version. Developing a new release takes a while, so the directory "1.0" was created well ahead of time. Unfortunately, a publisher of CD-ROMs, prematurely mass-produced a disc they labeled 1.0, before Debian had actually finished making 1.0. This meant that people who got the Debian 1.0 CD-ROM got something that wasn't actually 1.0.

An obvious solution to prevent this from happening again would have been to prepare the release in a directory called "1.0-not-released", and rename the directory to "1.0" after the release was finished. However, this would've meant that all the mirrors would've had to re-download the release when the name of the directory changed. That would've been costly, given the massive size of Debian (hundreds of packages! tens of megabytes!). Thus, Debian chose to use code names instead.

Later, the "pool" structure was added to the Debian archive. With this, the files for all releases are in the same directory tree, and metadata files specify what files belong to each release. This makes mirroring easier. It might be possible to drop the code names and stick to versions, now, but I don't know if Debian would be interested in that.

Changing slowly

As implied above, Debian is huge. It's massive. It's enormous, It's really not very small at all, any more.

Large ships stop slowly. Large projects change slowly. Any change in Debian that affects large portion of its packages may require hundreds of volunteers to do work. That is not going to happen quickly.

Sometimes the work can be done with just a small number of people, and Debian has processes to enable that. As an example, if a new version of the GNU C compiler is uploaded, the work of finding out what fixes in other packages need to be made can usually be done by a handful of people.

Often a change takes time because there's a need to build consensus, and that requires extensive discussion, which takes time and can only rarely be short-circuited.

This all also means Debian developers tend to be conservative in technical decisions. They often prefer solutions that don't require large scale changes.

To comment publicly, please use this fediverse thread.

2025 update: I've posted a followup Why does Debian change software?.