Note: This is just something that I wanted to write for a long time and thought to write it out given the recent posts about JavaScript and Clojure. This is just common problems and sometimes I even committed some of the mistakes mentioned here. I may have some instances of my own mistakes as an example to drive the fact but it’s never a personal attack on anybody. So take this is a piece of opinion with salt like other posts.

My first experience with open source was in the form an Android app, Wordzilla that I open sourced back in 2014. It was cool to see people using it and some people asked me about license for using the database. I had no clue and said please do whatever you want. I tried contributing to some tools I use and fixing up some personal itches and grew up from there. I am not a very big contributor but kind of worked in my own pace since I feel working on open source for long continuous periods is hard unless you do it full-time or involved with a large project. I am grateful for the work of others and felt good in my code helping others. But I also got to know more about why it’s more than code in maintaining large software projects and this is mostly a post on some of the mistakes I did and things common in open source.

Time and interest variables

A large part of open source projects start as a personal itch like you want to solve a problem for which you don’t find a library and you end up writing one. X language has a library but you use Y and you port the library. You tend to open source the project in hope that it might help someone else. Some projects pick up steam and grow a community and other might just end up as your own little experiments. Either way you put in time and effort. Like all the other things in life you move on to some other languages/domain writing more code or you don’t even write code anymore. Someday one user might have their own personal itch and want to add a feature to the project. They will raise a PR and even a simple one but you don’t want to maintain it anymore due lack of interest. The most common answer with open source is to ask the user to fork it. A lot of languages support using libraries directly from git but they might still want it upstream so that they can install it with the package manager or as a sense of satisfaction seeing their own code being part of a project.

So there is conflict of interest with the user urging the maintainer to merge the code. They might be busy with their other projects or activities given their limited time and priority which the user might have no clue about. Sometimes someone makes a nice feature request and the maintainer adds some polishing comments but the user just disappears with the PR languishing. It happens in all the projects small and large and with small projects being dependency of a larger one. Time and interest are highly relative enough that what might seem more important to me might not be of any interest to the maintainer anymore and vice versa. It’s common human nature to put more emphasis on what we need to accomplish and it takes a little more time to understand the variadic nature of time and interest on both sides. Well on the user side you might say well if you don’t maintain it why not transfer the ownership to someone else.

Trust is crucial but not measurable

Large parts of the open source communities are built upon trust since a lot of work just happens across the internet. I might start contributing something and with trust grows over time based not only on contributions but how I communicate with others, respond for feedback/criticism, prioritize and so on. Pretty much like a relationship several factors contribute towards trust and maintainers act upon the trust gained upon the interactions since you never get to know a person more than that or see them in real life day to day like a coworker. But they all can be manipulated and also change over a period of time. The nature of the contributor after a lot of years might be different than the day you gave access to their project. Also trust is not really measurable in quantitative terms except that you can act only with the best of interest and benefit of doubt.

Even with face to face meetings it’s kind of hard to measure trust and they might seem like a good chap in some aspect but a complete jerk to someone/something else that you might never know and even only get to know over the course of time that may or may not affect the project. With people from different countries, race, gender and conditions of life that you get to deal with on the internet it becomes even harder to quantify trust. Maybe it’s something that the communities need to deal with benefit and might need to enforce trust and better behavior like CoC but we are humans. So when you transfer the maintership you are also entitled to vet someone you never met based only on the interactions with them. When they end up doing something nefarious then you are again entitled to act upon their actions. So there is another layer added where you are entitled not only for your behavior but also for someone else. So that brings me to the next topic of entitlement.

Entitlement and cost

When people release some project that ends up large then they are also entitled to maintain it or transfer maintenance or be clear about the deprecation once you don’t maintain it anymore. In large projects you are entitled for the most part in any one of the category. For the first option it might be powering large parts of revenue for a company though you work in another company and you have very limited time to juggle between a day job, family, friends and your own interests out of code. In case of maintenance transfer you are also entitled to vet people based on trust before you transfer them. With the third case you might not have interest even given the money due to other projects and you need to deprecate it but you are entitled to maintain it just for the sake that it’s part of large infrastructure like a social service. These things all come at a cost of time that cannot be obtained back. There is also economics factor of life that you have to earn to pay your bills and at some point you thrive for better financial stability that might conflict with your involvement with the open source project.

There is a general expectation among the users of open source to make sure you spend more time on the project as if you have to do it at the cost of your own labour being underfunded or working on something that is clearly not a priority despite money. There are funding platforms and many other platforms that are great but it never has to come at the cost and expectation that the developer has to do underfunded labour just in the name of working on open source as if doing greater good to mankind. They are not sustainable in the long term and the satisfaction of seeing your code rake billions of dollars is great but then again the satisfaction doesn’t pay daily bills and you might even want to lead a better financial life deriving more value out of your skills. So people working on their own time in open source projects shouldn’t be treated as non-profit workers because they have the benefit of developing open source and at that point it’s just underfunded labour deceived as open source to derive more labour.

A lot of experiences like this might even cause frustration and burn out driving away people along with developing fear over the course of time where people don’t want to open source their code anymore over maintaining it or the community altering with interest of the original developer. I don’t really know any solution to solve this and of course more money to open source projects thus developer has more share of their bread with the project but is not really a solution all the time. I can go on about conflicts of interests over the design, other bike shedding, health and personal problems of the maintainer reducing involvement and so on but I will stop here. So next time you make a (simple) feature request or bug fix that languishes for a long time it is not a simple click of the merge button!

Makes a PR and merges to master