Open Source Software – Where to Find Requirements Specifications

Don't let the software prevent you from seeing the projects.

I challenge the idea that you need requirements for a software. And suggest that requirements are for software projects. And that there are many software projects in the making of a software. Of those, only one was the inception, and that one is often the worse documented.

Alright, perhaps from a more philosophical point of view, software have requirements from the moment the idea of them is conceived is the mind. But you are not getting to see those. For a practical stand point, there will be projects.

Free and Open Source software has multiple ways to advance. The software is the software (across all its versions and editions), but each change is a project. Each one of those projects has requirements.

Bug Reports.

There are people who test and use the software, and submit bug reports (issues). Fixing them becomes the requirement for the project of, well, fixing them. Some time a change is done to address multiple bugs, in essence collecting those issues are requirements for a single project.

Ah, but let us talk about adding features…

Road-maps.

It is common that a lead programmer will have a road-map of features to add. Which could be public for everybody, could be shared only among maintainers/core developers, or could be entirety private. The core developers will work towards the what is laid out in road-map.

Proposals.

You will also find the issue system co-opted for feature requests. In fact, the practice of writing proposals for change as issues is becoming widespread. These proposals are usually more detailed than a road-map. You can consider them RFC documents.

The issues, in the issue tracker. Be them bug reports or proposals for new features. Those are requests for change. They bring new requirements (or remind of old ones in the case of regressions). To implement those changes, we do projects (with design, and testings, programming, etc). To reiterate, each one of those projects has requirements.

TO-DO lists.

Some of us will have private, never seen by the public, TO-DO lists. Which can be as detailed as needed. Those can be considered requirements, but they never get to the repositories.

For example, I may turn an issue into a TO-DO list, work on it, and delete the TO-DO list when I'm done. Oh, and let me tell you about moments of inspiration. I've learned to portray these ideas quickly. Formalism may take too long. And the idea can be too large to implement quickly. I find the TO-DO list format useful in those cases.

Ah, by the way, some tools can pull TO-DO items from source code comments. Keep an eye for those.

Pull requests.

Contributes may come from outsiders. As third parties can fork the repository, modify the source, and then have those modifications incorporated into the official repository (with approval of its maintainers). This process is formalized as pull requests. How did they manage the requirements for those changes? Each developer does it their own way.

In fact, you may find common that they only express the requirements after the fact. Often to explain what the change does, in order to have it approved. And that can be dealt with in a conversational manner, instead of formal document.

Milestones.

Furthermore, you will find milestones. Usually corresponding to major releases. For a milestone a set of issues (bugs to fix, or features to add) is selected. You may consider all those as requirements for the next release.

Tests.

For some folks following TDD, the tests are the requirements. Even for those of us who don't follow TDD, having the code pass all tests is often a requirement for a new release. Thus, those are requirements expressed in the very formal language of actually executable code.

I remind you that automated tests, unlike requirement documents, are very good at telling you something is broken. Ah, yes, put writing tests in your DO-DO list, and require tests to have pull requests approved.

After all, both design and tests should come from the requirements. And if I don't have to do estimation, or have my project approved by management, or negotiate requirements with a client… I could start expressing my requirements in the form of automated tests, interfaces and other forms of code contracts. So I get to writing code faster.

I'll also remind you that many open source software come from a personal need. In many cases, the founders of these project started them because they needed the software, other times the founders really wanted to create the software out of passion.

And I'll remind you that not every developer is a software engineer. Not everybody needs and is trained for formality in methodology.

I hope it is not hard to imagine for you that the requirements for new born software can be "it helps me in my situation". At the start it could have no formal iterations or milestones, those thing you can added to the workflow later. At the start what matters is whatever or not the software is an improvement over nothing for whatever the founder is doing.

So, no, you are not going to find a requirements document for the entire software. However, you will find requirements for releases, or for particular changes. Don't let the software prevent you from seeing the projects.