So what makes it all tick? In this exciting conclusion, we'll pick apart the key components of the open-source ecosystem, from the motivations of contributors to the leadership style necessarily implied by them.
GNU/Linux can be likened to a 500-piece puzzle with 2500 available pieces: For any piece of the puzzle— shell, desktop environment, web browser, right down to C libraries and kernels— there are around five competent options to choose from.
The operating systems built from these parts have a few characteristics in common:
Technically, GNU/Linux is a "class" of operating system.
The modularity that exists through the "package" concept was neither planned nor intentional, but emerged as GNU/Linux matured into a fully capable platform. The package, and in turn the project, has become a central organizing feature of GNU/Linux.
Many smallish projects allow users to shape their system as they desire, allows contributors to promote modifications to a given part, and allows developers to reasonably introduce a new component, as they desire.
One of the remarkable things about GNU/Linux is that no one person (or organization, for that matter) is responsible for the production of an entire operating system. Rather, collecting and assembling the parts is a project of its own, distinct from, say, shell development.
Compared to the market economy we all know and love, open source is a strange beast: Its works are created because what they are is what their creators want. Stated another way, the intent of free software is the software itself. This differs from proprietary schemes, where the point of software is the profit it promises.
Goods produced for their own sake are said to have intrinsic value, and this, in turn, underpins open source. Intrinsic value is found in many places, such as academic research and art on public display. It's the reason you take out the trash, go to the gym, or plant flowers.
Stated more plainly, we are not in the business of pleasing other people. We are in the "I have an itch and I'm gonna scratch it," business.
It's easy to mistake contribution for altruism, but that would be, well, a mistake. Rather, the existence of a bug or the absence of a feature motivates modification, which then works its way into the appropriate project.
Projects can attract commercial interests, as well.
Facebook taking part
in the development of Linux's new
btrfs
is one such example.
But note that, in this case, as in most other cases,
the principal interest is in the software per se:
It is developed to be used, not to be sold, and is therefore
developed for its intrinsic value.
If intrinsic value were indeed the principle motivating force of the open-source ecosystem, it would follow that those projects with the greatest number of use-cases garner the greatest support. In support of this, note that the largest free-software organization to date is neither GNU nor Linux, but the Apache Foundation, whose projects underpin the world wide web.[1]
Although open-source canon states that every user is a potential developer, in practice the majority of development is thanks to a relatively small group of people.[2]
Open-source projects are typically organized around a small group of core developers, called maintainers. Maintainers have the ability to modify the work however they want, and accept user-born modifications as they see fit. Maintainers offer new versions as they become mature, and in so doing present the work to the world.
You can judge the relative health of a project by how recently it's been modified. More recently is better.
Maintainers work diligently over years to present a polished product to the world, and have earned the trust of the community; they are the most important people of open-source, and are the "owners" of their respective projects.[3] An open source software project without a maintainer has effectively been abandoned— or it is looking for a maintainer :) .
With a common, shared goal— the project itself— the contributors to a project form a community. As Ted Dunning put it,
"We as people come together; we have some communal interest. As such, we build a structure together that allows us to work together, allows us to communicate, allows us to bring in new people, and build software together. This is definitely not the fastest way to build software, but it's a remarkably sustainable way."[4]
Especially about large and popular projects, maintainership can become a matter of curating modifications. Very large projects (like the Linux kernel or the Firefox web browser) have been broken down into subsystems, with each subsystem having maintainer(s) of their own. The result is that user-born modifications first pass through the appropriate subsystem maintainer before being proposed to the project's overarching maintainers, before finally being accepted into the work itself.
The components constituting a modern GNU/Linux system were not created overnight, but rather through a slow process of elaboration and refinement. This gradual improvement is a kind of continual improvement process, and follows a clear pattern: Deploy, study, improve, repeat.
The Linux kernel, for example, gets re-released every six weeks.
It may seem strange that a project would be released before it is complete, but in practice software is never "finished." It can always be improved, and for proof of this, one must only look at the sequence of releases given by proprietary projects.
In practice, open-source software is given away for free, attracting users. Since sources are available, interested parties can inspect its construction, and identify areas that could be improved. Their modifications generally, but not always, work their way back to source; under the guidance of maintainers, projects stay on course.
Even marginal improvements accrue, and with each successive iteration, the software becomes better-able to serve its users. Large numbers of iterations see fantastic improvement, and results in products that are polished and whole.
Maintainers generally prefer small improvements to radical ones— Bear in mind that they have probably been maintaining the work longer than you've been studying it. Individual improvements usually tackle one of two items: Bug fix or feature addition.
less
A paging utility is a program that displays a file,
one screenful at a time.
The first widely used paging utility was more, written by
Dan Halbert as a graduate student at UC Berkeley in 1978.[5]
more is a simple program: It first
fills up the screen, then waits for user input to print the
next lines.
In 1983, Mark Nudelman was a software developer working for a
company called Integrated Office Systems. From the less FAQ:
Some of our software ran on a Unix system and produced enormous log files of its transactions. We wanted to be able to search these log files for error messages. But the version of "vi" we were using couldn't handle files larger than a certain size, and our log files often exceeded that size. So we were forced to use "more" to view the files. The problem was, once we found an error message, what we really wanted to see was the transactions leading up to the error; that is, the lines in the log file immediately before the error message. But more didn't allow backward movement in the file.
We often complained about this problem. We said we needed a "backwards more"; someone (it wasn't me, but unfortunately I don't remember who it was) coined the name "less" as a joke on the concept of a "backwards more". It didn't seem to me that it would be too difficult to write a simple pager that would allow forward and backward movement. I wrote the first version in late 1983 and we began using it internally. I continued to enhance it and finally decided it was a useful enough tool that I should make it available to the world. I posted the first version to the newsgroup called (at that time) net.sources in May, 1985.
Making the program publicly available allowed an enormous number of people to use it. Many people have made their own modifications and donated them to me for incorporation into the official version, and many more have reported bugs they've found or made suggestions about features they'd like to see added. This was my first experience with the concept of what is now called "open source" or "free software", and it has, I believe, produced a very high quality product. I'd like to thank all the users of less for their invaluable comments and suggestions over the years. Less wouldn't be what it is today without you.
Mark Nudelman continues to maintain less today.
It is, at the time of this writing, on its 590th
revision.[6][7]