9.1 Don’t Install a Feature Till It Works on GNU

Please don’t write or install code for features that would have worse or less functionality (or none) on the GNU system than on some non-GNU systems.

The primary purpose of any GNU program is to enhance the capability of the GNU system to give users freedom, so every feature of a GNU package should be usable and useful on free distributions of the GNU operating system (https://www.gnu.org/distros/). For this purpose, a “feature” is an operation which does something substantially useful for the user and not the technical details of an implementation. We explain this point further below.

A feature that functions only on, or functions better on, some non-GNU operating system would undermine that primary purpose; worse, it would promote that non-GNU system at the expense of GNU. Such a situation would work directly against the goal of liberating users from those systems, even though installing features that create such a situation would be seen as desirable in terms of the “open source” philosophy.

Since freedom in use of computing is the overall purpose, we need to aim clearly for that freedom. We need to show with our practical decisions—and with our explanations of them—that we’re working for something deeper and more important than “better software” and “more convenience.” That will give users a chance to reflect about our reasons for taking a path different from what most programmers would do. See https://www.gnu.org/philosophy/open-source-misses-the-point.html.

Therefore, when you as a GNU maintainer receive contributions of features that do not work on the GNU system, please explain this rule and why it is necessary. Explain that we need all features in GNU packages to work properly on the GNU system, so that they potentiate each other and make the GNU system better. Thus, the change should not be installed in its present form.

That doesn’t mean the change can’t be installed ever. It could be installed later, if and when equally good support on the GNU system for the same feature can be installed at the same time. Explaining this is a good opportunity to ask people to help write the code to support the feature on GNU. Also inform the contributor about resources to learn about how to support this feature on GNU, so perse could consider doing that job—or recruiting others to help.

If parts of the code are system-independent, and will do part of the job of supporting the feature on the GNU system, you can install them right away. Or you can put them in the package repo without actually installing them, in a ‘wip-name’ branch. Having them in the repository may help and encourage people to finish implementing the feature on GNU.

If you think it is very important, you can implement the support for that feature on the GNU system yourself. If you think it is highly desirable to have that feature on GNU someday, you can make special arrangements to put the non-GNU system-specific code in the package repo but not install it—see Uninstalled Code in Repo.

It is ok to implement or support a feature for non-GNU systems if the feature works at least as well on GNU, even if it is implemented differently on different systems, uses different system facilities in its implementation, or looks different to the user in some details. It is ok to implement those little details, on each system, in the way that is convenient or conventional for making the features work. The point is that the program and the feature should “run best on GNU.”

If system facilities on some other system provide, without any special application code, a feature not available on GNU, there is no need to do work to prevent it from functioning. In that case, we should work to implement that feature in GNU.

We don’t consider the little details of interfaces to control or configure specific operations, or details of implementing operations, as “features.” Likewise, a system facility (including libraries that come with the system) is a means for implementing features but use of the facility is not in itself a feature.

For instance, a programming platform often offers an interface to control the computer or the operating system at a low level. It is OK to support the feature of low-level control on a non-GNU system provided the package supports the same capabilities on the GNU system also, even if the details of how to invoke the feature vary from system to system. But do undertake to make the invocation of this feature consistent across systems, for the specific actions that are supported on multiple systems.

Features mainly for communicating with other users’ computers, or between computers not set up for tightly-coupled use as a group, are a different matter entirely. A communication feature is truly “the same feature” as on GNU only if it interoperates with a free distribution of the GNU system—as, for instance, TCP/IP does. Unportable, system-specific communication facilities for non-GNU systems are abuse of the community, so don’t install support for them. This point also applies to file formats used for communication between programs, if there is ever an occasion to move those files between unrelated computers. (Exception: it is admirable to write code to extract the user’s data from such a file, if you can do it.)

Finally, please be careful not to let installing or supporting system-specific code for non-GNU systems consume much of your own time. See GNU Coding Standards in GNU Coding Standards.

Suppose people ask for support for feature F on some non-GNU system, and feature F does work on GNU. You can say yes if you wish, but you have no obligation to write or maintain that code. You can tell them that it’s their responsibility to write it and maintain it. If they write good clean code for it, you can approve its installation, but that doesn’t mean you or anyone else is obliged to support it. If someday the code suffers from bitrot, you can delete it if users don’t fix it.

See Suggested Responses, for some text you can use or adapt, if you like, to say no to these patches. It aims to invite them to support the GNU system equally well in the new feature. If there is no hope of that, just “No thanks” is enough.