Fork My Code, Please!

Fork My Code, Please!

An Open Letter To Those of You Who Are Unhappy

We maintain two prominent Free Software packages, owned and distributed by the Free Software Foundation. Between us we have 50 or more years of experience with:

C language programming

Unix and Unix-like systems

Maintaining and enhancing significant programs<br>used by millions of people every day

We are proud of the work we do, and overall, we enjoy it and are happy for having spent large chunks of our lives in making the world a better place through our activities.

However, there are some things that you may know, but which we would like to remind you of.

WE ARE VOLUNTEERS. We do not get paid for the work we do. This means:

We don't owe you anything. Just because you<br>want a feature or a change in behavior, we are not obligated<br>to provide it, instantly or at all. We have to balance<br>the desirability and broad usability of a feature against the<br>effort required to implement and support it.

We are not on a schedule. We each have lives<br>(day jobs, families, even other interests), and we do<br>not have to produce releases just because someone else<br>is working to release a distribution that includes<br>our code. (We may try to accommodate them, but we don't<br>have to.)

We can (and do) run the projects as we wish.<br>We are under no obligation to make our source code<br>available in a public distributed source code repository of<br>any kind. Should we choose to do so, we get<br>to make the choice of version control system to suit<br>ourselves, and use it in the way we find most convenient.

We use the development environments we prefer,<br>though we try to use the GNU tool chain everywhere.<br>(One of us has been scolded several times for not using a<br>particular Unix-like system.)

COMPATIBILITY IS A P.I.T.A. What does this mean?

A goal and guideline for GNU software is to be<br>compatible with the POSIX standard(s) and with existing<br>practice as much as possible. This is a worthy goal.<br>It allows people to move their software and their skills<br>amongst different systems with little hassle. If you<br>object to a particular POSIX change, remember that the<br>committee has probably already considered your argument and<br>decided to go a different way.

The flip side is that even when we know that some things<br>could have been done better,<br>we are not free to make gratuitous changes. We<br>are not idiots. We understand quite well that the<br>original designs of the programs which we have cloned were<br>not perfect. But it's just too late to improve things<br>in incompatible ways.

The user base has come to rely on our programs and how they behave.<br>Even when we made a mistake in something early on, if it<br>was too long ago, millions of people have come to rely upon<br>the existing behavior, and we can't "fix" things,<br>even when we want to. (Even if we have documented that "at<br>some point, XYZ will change".) If we do so, it's<br>in service of points (a) and (b) above.

On the other hand, we will fix clear bugs, even if that<br>may break something. We're sorry if you wrote code that<br>relies on such bugs.

Compatibility modes, or making programs behave differently based on how they're run, are poor solutions<br>at best and lead to inconsistencies that are hard to explain<br>and diagnose. We try to avoid them where we can and<br>resist the temptation to make everything dependent on them.<br>Please don't ask us to use them for every change you don't like.

We are glad to receive input from our user community about:

Real bugs (defined as: behavior that differentiates from the formal<br>standard, or from historical practices, or is obviously wrong [such<br>as a core dump], but not "it's a bug since it doesn't work the<br>way I think it should". (It's fair to ask that<br>question, but be prepared for the answer to be "no.").

Documentation problems.<br>Documentation comes in three flavors: reference, tutorial, and<br>cookbook.

The purpose of a reference is<br>to explain how our software works. The purpose of a tutorial<br>is to<br>help you understand how to solve your problems using our software.<br>A cookbook gives you lots of predefined recipes to solve specific<br>problems.<br>Don't expect a reference to be a tutorial, and don't<br>expect a tutorial to be a cookbook.

So, bug reports of the<br>form "Your manual doesn't explain how to use XXX to make<br>cappuccino!" won't be given much consideration. Similarly,<br>reports of the form "Your manual doesn't say that Ada packages<br>are not supported!" (this really happened to one of us) are not<br>helpful. The number of things that any given piece of software<br>DOESN'T do is, by definition, infinite.

Suggestions for new features that:

Cannot be accomplished using existing features in a<br>straightforward way

Don't (too badly) break compatibility for existing code

If you think you know better than we do,<br>we welcome discussions that:

are polite

are well reasoned

refrain from personal attacks and insults

refrain from demands upon us based upon our "obligations"<br>to do whatever you think we are obliged to do<br>(see...