One of the fantastic things about open-source projects is the ability for all people regardless of their backgrounds and distance between them, to work together on new projects. If you see something that's incorrect, you can attempt to fix it yourself, or contribute ideas to people already in the progress of fixing whatever it is that's incorrect. Unfortunately, though, time and time again, this is used as an excuse by many projects not to fix things themselves. As indicated by some of the responses to my previous analysis about the state of IPFS, there were a few routine points brought up that is brought up time and time again anyone says anything wrong about open-source software:
- You can fix it yourself
- It's an open-source project the community is encouraged to maintain the library
- Many projects exhibit uncoordinated development
- It's pre v1 software
You Can Fix It Yourself
An extremely valid point, but it is a bit misleading, not to mention that this then becomes a crutch for the projects and a way to dismiss valid claims against the state of various projects. If a project could always have people fix the problems themselves, what's the point in the project maintainers existing? Should they take a backward step, letting the community do all the work, while the project maintainers sit back and reap the profits and financial gains? Reap the benefits that come with people fixing your problems for you, allowing you to sell your software and services to more people and not have to pay for the fixing of issues caused by your workers?
Additionally fixing software requires a few things:
- Collaboration with maintainers of the software
- Pull request reviews
- Time
Collaboration with the maintainers of software isn't always a smooth process. Project maintainers very staunch in their beliefs and their decisions, often react with hostility whenever someone points out a flaw. Project maintainers that are very nit-picky will even suggest changes, or outright refuse a fix, even though the alternative is worse.
Pull request reviews are a necessary task for code development, otherwise detrimental effects occur, like bugs being injected into codebases because there were no second pair of eyes on the code. But as is typical with many pull requests, there is a lot of back and forth. Unfortunately, in many cases, this results in long delays either waiting for the maintainer to respond, or even maintainers just completely forgetting about things.
Perhaps the essential aspect of all this is time. When contributing to open-source projects, contributors are seldomly financially paid, which means taking time out of their lives to set aside for on the open-source contribution. Not everyone can do this; not everyone has the time in their lives to dedicate to freely contributing code to open-source projects and not get paid for it.
It's An Open Source Project The Community Is Encouraged To Maintain The Library
As with the previous point, this is used as a claim to dismiss negative criticisms of open-source projects. It's not the community that owns the library. It's not the community that bears the primary responsibility for the production of useful software. It's also not sustainable that anytime someone has a problem with something, they fix it themselves. Businesses are using IPFS, and the very nature of IPFS being new means businesses have to spend time (spend more money) dealing with the integrations.
At what point does it turn from having the community contribute to libraries, to having the project maintainers denying all adverse claims, and depending on the community to fix issues for them? It is entirely unsustainable to depend on open-source communities to fix code issues. Furthermore, not all problems are fixable in code. Some issues are due to poor decisions made by people, and this is not something the community can fix.
Many projects Exhibit Uncoordinated Development
If many people are jumping off bridges, does this mean you should do it as well? Bad practices are bad practices plain and simple, and there is no excuse for continuing with bad practices only because other people are doing the same. If the project is very new and being lead by people unfamiliar with the leadership, it is understandable not to be so critical about harmful practices. But when a project isn't new, when it has established roots, been around for a while, has a healthy-sized team of people, and funding to hire some of the top minds in whatever industry their in, is it understandable? As with depending on community fixes, should we outright deny claims, simply because the problem it's talking about is problems that aren't exactly uncommon? I take this stance about code development, about anything really, it encourages stagnation and creates an environment where progress is few and far between.
It's Pre Version 1 Software
Just because something is pre-version 1, doesn't mean we should discard all good practices and all criticisms. Pre version 1 software is far too often used as an excuse for terrible development practices, and as an excuse not to take problem fixing seriously. IPFS is nearly five years old, used by dozens of companies, and has an active network composed of tens of thousands of nodes. This is not a network of pre v1 software users. It's a network of people depending on the IPFS network for business continuity, people depending on the system in ways that are not suitable to pre v1 software.