Fork My Code, Please (2014)

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

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

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

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

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

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

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

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

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

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

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

   4. Compatibility modes, or making programs behave differently based on how they're run, are poor solutions at best and lead to inconsistencies that are hard to explain and diagnose. We try to avoid them where we can and resist the temptation to make everything dependent on them. 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 standard, or from historical practices, or is obviously wrong [such as a core dump], but not "it's a bug since it doesn't work the way I think it should". (It's fair to ask that question, but be prepared for the answer to be "no.").

• Documentation problems. Documentation comes in three flavors: reference, tutorial, and cookbook.

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

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

• Suggestions for new features that:
  • Cannot be accomplished using existing features in a straightforward way
  • Don't (too badly) break compatibility for existing code
• If you think you know better than we do, we welcome discussions that:
  • are polite
  • are well reasoned
  • refrain from personal attacks and insults
  • refrain from demands upon us based upon our "obligations" to do whatever you think we are obliged to do (see point 1.1, above)
  • take into account the constraints (historical and standards compatibility, portability) under which our software has to function
  • acknowledge that all users are not identical, and that very few people are perfectly representative of the entire user base

However, if the thrust of your argument is "the behavior is wrong because it doesn't work the way I expect it to", then we don't really want to hear it. (Unless, of course, you happen to be Brian Kernighan, Ken Thompson, Steven Bourne, David Korn, Al Aho, Peter Weinberger, or Rob Pike.)

It may be that, after reading all of the above, you are still unhappy with how our programs behave, and/or with our stewardship of these programs. If so, we hereby invite you to

We both got our start reading and tinkering with others' code. This is the best tradition of Free Software. It's why source code is available and easily modifiable.

We would welcome the healthy competition that would be provided by a code fork. That's what Free Software and the GPL are all about. So put your money where your mouth is, set up a project on SourceForge or somewhere else, start with our code base even , and please show us how to do it better!

It may be that you can do a better job than us. In that case, the Free Software Foundation might even ask you to take over stewardship of the program (this kind of thing has even happened in the past).

Even if you are not prepared to undertake the maintenance of an entire project, the opportunity to tinker and prototype new ideas yourself, without relying on someone else to get to it, will help you.

We have occasionally explained to people like yourselves where in the code to change the behavior they would like to see changed. We often get a reply like "I don't know how to program in C!" or "I only use my package manager, I won't build a program from source."

In that case, you may wish to talk to us (offline) about our consulting rates. Surely, if you want badly enough to see the behavior changed, you'll be willing to pay us to do it for you, right? And, if you don't like our qualifications, the FSF maintains a list of consultants who will work on Free Software for you; perhaps one of them will work out better for you.

Sincerely,

Arnold Robbins

Chet Ramey

Initial version: April, 2012

Small revision, September, 2014