Chris Tankersley

The Contracts of Open Source

Posted on 2020-11-30

Many people do not realize how old the concept of open-source software is, or that that software basically started as a shared development experience. In the 1950s computers did not come with software for the most part. Developers would be forced to develop software for the platforms that they had access to. Since many of these early developers were introduced to computers during college, one of the few institutions that could afford even machines like the TX-0 or the A-2, the general ideas of academia bled into software development.

These developers, be they students or faculty at the schools, would share their software just like they would share knowledge. This fed quite well with the early hacking ideas of "Information Should Be Free." If someone developed an algorithm or a utility it was shared amongst everyone else. Early hacking culture introduced the idea that it was also fine to modify the software. The unwritten rule was that it was shared.

Software in its infancy was open source, we just did not have a name for it. The idea of commercial software was not even considered. Software from even the machine vendors was just considered part of the machine. You purchased hardware, not software. You created the software and shared it with your colleagues. If you had a problem with the software you could talk to the author, or you fixed it yourself. There was no expectation other than the sharing of knowledge.

Fast forward a few decades and commercial software start to appear. As machines become somewhat more standardized and development starts to become more costly, developers like Micro-Soft start not sharing their software but selling their software. Software becomes a product and begins to unbundle from the hardware. Need a compiler? That will be an extra cost of $60-$75 on top of the hardware.

The ideas of open source never went away. Systems like the Berkeley Software Distribution for Unix flourished despite AT&T's attempts to lock down the licensing of the early Unix source code. The GNU Project was formed in 1983 with the explicit purpose of making sure that users keep control over the software that they run, and have the freedom to modify it as they see fit. In keeping with the early developers and hackers, the GNU Projects forced developers to share their modifications but gave them the ability to study and copy software as well.

Much of the modern web only exists because of open-source software. Apache's httpd has and continues to power a huge swath of the Internet as a whole. Subsystems for communication like e-mail are more often than not powered by open-source software. Windows had a networking stack lifted from BSD. Companies like Mozilla and Redhat power the internet and give developers and users open-source options for their software and operating systems. If open-source software would disappear, the tech world would come to a screeching halt.

When a developer decides to put their time toward open-source software, they are giving up their time and sharing their expertise. Despite all the grumblings about not owing users anything, most open source developers spend time working with and listening to users and other collaborators to make their software better. They build tools and programs to make their lives, and by extension others' lives, better.

There is a contract that is established when using open-source software. I do not mean the license, a legal document that spells out what you can and cannot do with a piece of software. There is a deeper moral contract that both the developer and the end-user enter into.

The contract says that the developer of the software is giving up their time for the greater good. To make sure you can use the software as you see fit, they give up the secrets of that software so that the user has access to their knowledge. The user can dig into the code and see how it works. The user can change the software as they see fit, no matter what the original developer designed. The user should share their knowledge about the software with the rest of the world through patches and collaboration.

The contract does not state that the original developer must follow the whims of the users. The contract does not state that the original developer owes the users anything. If a user feels that something is lacking, the user is expected to collaborate or do the work themselves. Are the docs lacking? Anyone can write docs for open-source software. The original developer is free to ignore the work done by users if they see fit. The users are just as free to post the docs even if they are not wanted.

I find it despicable what Sebastian had to endure with PHPUnit and PHP 8 support. Sebastian, as the original developer and maintainer of PHPUnit, is more than free to dictate how he spends his time working on the software. If there is a demand for PHP 8 support, he is more than free to weigh the pros and cons of adding that to older versions despite what he has already noted as his support structure for releases.

If you wanted PHP 8 support in older versions, you are more than welcome to fork the software and add support for PHP 8. You are welcome to work with Sebastian to try and get it into the official releases, but Sebastian is not under any obligation to give in to the masses. He has already given the tools needed to modify PHPUnit freely to the world. His knowledge is laid bare in the source code.

If PHPUnit is not to your liking, study the code, and modify it yourself. Distribute the patches and the forks back out to the world just like Sebastian did. That is the power that open source gives you under the contract.

I think a large number of developers forget that many open source projects are run by individuals. These individuals seldom make money directly on the software, but hold other jobs to pay the bills or maybe sell ancillary services around the software they build. Unless you are specifically paying Sebastian as a contractor to modify PHPUnit to your liking, you do not get to demand anything of him or any maintainer. You can ask, and he can say "No." If you do not like that answer, the source code is there for you to change.

When a library is changing too quickly for your liking, you are free to stay on an older version. Most developers do not remove older unsupported versions of libraries or applications just because a new version is out. If a developer wants to support older versions of their software, that is a decision they make. That is not a decision the users make. You are making a conscious decision to stay on that older version, and you need to live with the consequences of that decision.

If your hands are tied because of an outside force and are unable to upgrade, the only advice I can give to you is to implore those that have the power to make that decision to upgrade. If it is a boss or a CEO, make the case. Explain why upgrading is beneficial, and how staying behind is becoming a drain on development. You must complain to those in power about your situation, not to the developer of the libraries and tools you use. Those developers' obligation to you ends when they share their knowledge and software.

When you use open source software, remember that it was built on the ideas of "Information should be free," collaboration, and the betterment of everyone.

There are humans behind that source code you are using.


Comments