Lessons from open source software
After creating and contributing to open source projects for almost a decade I have noticed some valuable patterns that are not always emulated elsewhere, especially in corporate environments.
Friction matters a lot
The harder it is to understand and contribute to the project the less likely people will. Open source projects will usually answer all of these questions:
- A readme file describing what it is, how to use it and maybe even how it works
- What is the license?
- How do I build the project?
- How do I test a change?
- How to I report a bug?
- What are the steps to contribute?
- What is the projects preferred communication channel (mailing list/irc/etc)
There is an incentive to make it easy to contribute back to the project. Developers will notice other projects that have easier contribution project and adopt the same thing.
A lot of these stem from the fact that open source projects are often both not the primary developers job and not the primary job of any external contributor. Everyone involved wants to be able to get in and make a chance quickly and easily.
Its source all the way down
With software you can go and see how everything and their dependencies works. You don't have to work around bugs, but you can fix them and contribute new features. You are not limited to the code base you are assigned, but if improving another projects solves your problem the best you can do that too. You can read the source code to understand how something works to be able to better use it.
In the same vein it isn't a surprise when others want to contribute to your code.
Development skills matters
At the end of the day the quality of the patch matters. The color of your skin, gender, sexuality, where you live, who your parents are, none of that matters.
Can you make good patch? Can you solve the problem?
Last committer wins
Anyone can sign up to the mailing list and discuss an idea of how things should be. Talk is cheap, where is the patch. And if there are a few different ideas, the one that continuously pushes the rock up the hill and improves the code "wins", not who has the better prose on the mailing list.
Code is public
Knowing that anyone can look at my code and eventually someone would caused me to change how I wrote code. Rather than writing code that one day I would make better I switched to always trying to write code I was proud of and to take the extra time to make it better even for small pet projects that no one else would ever review.
Code review is the default
When contributing to a project it is extremely common that someone will look at your code before it goes in. This results in better code across the board.
Doing the "right thing"
Changes that are quick little hacks are pushed back on much more in open source. As a result over time the code base is less likely to become filled with tech debt. The amusing part is often the "right way" is not much more work in the end.
Small changes are desired
Combine all of the above and when someone comes by with a very large change they will be asked to break up the change into smaller more chunks, each one doing one thing at a time. These are easier to review and iterate on.
They understand the product they are building
Open source projects are often used by those who develop them. And if it isn't them they are often talking directly to them. They understand who the "clients" are and what their problems are. They lean less to building random features and much closer to building the exact features that would make the most impact.
Many projects have a list somewhere that describe not only the goals but also the anti-goals of the project. Every project could eventually reach the point of being able to read email, but many well run open source projects understand what they are working on and don't accept those patches.
This also means that a project doesn't need to get features for no reason. If it is solving the original problem it can have a slow curn of bug fixes over time with the occational new feature. It does not need to come up with a new feature each quarter.
Awareness of time
If these could all be summed up it would be a general better awareness of time and a dramatically lower maintenance burden of the project. Open source developers don't have 40 hours a week forever to work on a project. It is something that is done in their free time and so they want to work efficiently. Many standard development techniques talked about in the mainstream I see in the open source world first years before.
Hiring
Hiring developers that have open source code I have noticed that they are exposed to a lot of things that those who have only worked corprate jobs have not. They have a better idea around building products over feature, understand technical project management, and are more likely to have higher code quality standards.