The Unbearable Lightness of Open Source Contribution
We have lived to the point where, in order to send your commit to a popular project, you do not need to sign a paper waiver of rights to the code, as was the case with GNU projects. Go to Github, search. Choose what you like, clone, create a pull request, feel like a proud contributor. But if you want not only to feel, but also to be, then everything is somewhat more complicated …
I would conditionally divide the contribution to the development of open source into 3 groups. For the soul – when you want to help a project that you consider useful, even if you will not use it. This includes mostly minor bug fixes. The second type is for a career, this is a case when you (being of sane mind and freedom of action) took an asterisk from the framework, and not put it, but the accepted commits to this corporate monster can have a beneficial effect on your portfolio. The third type of contribution is for yourself. When you use an open source program, you apply the same patches of yours from release to release, and you begin to suspect that this functionality may not only be useful to you.
For each case, I had my own motivation, my own reserve of patience and my desire to make concessions. And in each of the three cases, I gave up, although I tried to contribute to about 50 different projects – from console utilities like wget to the QT framework. Now more about what types of problems I encountered.
Great Indian Repository
Popular projects attract careerists. Contributing to them has long been a way to make a career with an extremely dubious or near-zero value of the contribution itself. Correcting typos is also the most innocuous thing to see among hanging PRs. Creating helpers and wrappers is half the trouble, as it is still easy to filter.
It is much worse when the entire Asian brotherhood begins to solve architectural issues and file down entire subsystems. Let’s say we have a php framework, which is not bad in itself, and it slowly grows overgrown with all the tinsel that seems to be needed, but according to the mood. Another Crawler, a frontend builder (God forbid it just be a wrapper around the normal!).
Depending on the persistence and multiplicity of the diaspora in the PR discussion thread, such contributions sometimes slip through. Against their background, your PR simply drowns. For the same reason, fixing bugs, even with established Issues, is more of a job for speed than quality.
Nobody needs it
You can satan for 5 years from the uncomfortable behavior of the program, from the lack of a helper or a facade, then finally decide and write a patch, make a PR, get a refusal, look at other rejected PRs … amazing PR for adding functionality that it would seem that no one in their right mind would do this. But they do. And you are with them. Behind you, the MUM is giggling maliciously, flying around the room.
Your vision
This is especially true for frameworks. Those who create frameworks and those who solve problems with their help are 2 different categories of people with their own thoughts. Practitioners and architects. Or even Architects and Architects. And two architects rarely get the same vision of architecture, even for simple cases.
Architecturally changing PR is the last thing when there is nothing else to drink. Or when you just want to troll your PR author of the project. Accept will not be accepted. But maybe at the other end of the world someone will blaze.
Fragments from the beyond
Astronauts of architecture sometimes fly far beyond the stratosphere. There they do not die from lack of air, but survive, and reach such a level of enlightenment that their approaches and architecture becomes clear only to them. In this case, attempts to commit metaparadigms to the next cluster are doomed to failure. After all, you are able to think only within your own paradigm.
I did it!
Asians especially suffer from this. The bottom line is that you send PR, it gets rejected, and without explanation. You sigh and start building the project from your fork, with all your patches you need. After a while, you notice pieces of your own rewritten code in the parent project. You don’t have to work for a large, ambitious corporation to suffer from Not Invented Here.
Party line
It happens that the author of a project is fixated on one thing. Porting to python of the third version, for example. And all features and bug fixes not related to this sacred goal are mercilessly rejected. Or, for example, we have a list of Issues and work strictly according to them. Bugs are not bugs, we have a purpose. Great and bright.
Honeypot for the motivated
It happens that PRs are rejected over and over again. Silently and nowhere. Without explaning the reason. Everything. The only time I saw any justification for this was that the author spent several years in his free time shoveling through the architecture of the project, so that most of the patches sent were really useless as a result.
It’s hard to say what is in the author’s head in this case. You just always need to remember that all your efforts can be thrown into the trash because, simply because.
Life-long PR
The longest period during which my PR hung forgotten is 3 years. I didn’t even know what it was about when I received the PR approval letter. Then I did not understand why I was writing this, but I obviously wrote it, which means I had some reason for it. I even used it once. Well, God bless him.
The bottom line is that the author, in addition to Github, also has a life that he is in no hurry to share on Github. And at the same time, he is smart enough to register Github on a separate mail, so that it does not distract a person from his life. Someone with might and main swears at evergreen activity, and someone perceives Github as a place where you can look at the mood.
So what is the bottom line?
I no longer commit to frameworks unless it takes more than 20 minutes, and there is a really unusual bug there. They will not accept it, so at least they will start an issue in which they will fix it as they see fit. After all, even with a properly formatted fix, you may be asked to write tests, which will need to spend a few more hours. And then, all the same, everything will turn into a reject and a line in the Caveats / Errata section.
In popular projects aimed at ordinary users, I commit on the basis that I will use it myself, and make patches on the basis that I will then pull changes from upstream and merge. They will accept – well, no – I will still get the functionality I need.
The most pleasant thing is to commit to every little thing. If it is useful to you and there is one and a half contributors. The authors are grateful that at least someone is using their project. You don’t need to maintain a fork. Everyone is happy. Zero career exhaust. Code quality requirements are near-zero.
Speaking of career exhaust. I think that today the threshold of your PR admission to a top project is simply not worth the effort spent on it. I’m not talking about the case when you are using something, and you are “lucky” to run into a bug and fix it first. And about attempts to develop the project, to make it better. Again, in the general case, everything is captured by a get-together, and what will be missed strongly depends on how close you are to this get-together. But if you actively use conditional PostgreSQL on large clusters, literally live by it, catch the rarest problems for rare situations, then this is a different story. People scribbling commits into a serious CD project usually have the right job and resource base for that. Or a social base.
So that’s about a career. Tasks with litcode give much more career exhaust. And if you want to develop swabble software, then be prepared that the fruits of your labors will not be needed by anyone. Therefore, try to make sure that at least you need them.
Don’t listen to employers who say that committing to open source makes you a good programmer. Only a programmer who is ready to waste his time anywhere with huge risks. Even ideology breaks down on the modern realities of contributing to large projects.
