@adlrocha -The dark side of open source software
… Duct Tape B*S* jobs
Let’s get things straight, I love open source. I am a great advocate of this model, it is one of the greatest things that could have happened to the development of the software industry (in terms of innovation, openness, and security). However, open source software has a dark side, the appearance of associated Duct Tape Bullshit Jobs. In case you are wondering, yes, I took this “duct taper” concept from David Graeber’s book (if you haven’t read this book yet, I highly recommend you do, it will definitely change the way you think about work).
So, what do duct tapers do? “Duct tapers are employees whose jobs exist only because of a glitch or fault in the organization; (…) basically, we have two kinds of jobs. One kind involves working on core technologies, solving hard and challenging problems, etc.The other one is taking a bunch of core technologies and applying some duct tape to make them work together. The former is generally seen as useful. The latter is often seen as less useful or even useless, but, in any case, much less gratifying than the first kind. The feeling is probably based on the observation that if core technologies were done properly, there would be little or no need for duct tape.”.
The Dark Side
And who’s responsible for some of these glitches in software-related companies? Open source software. Two decades ago, companies dismissed open source software and developed core technologies in-house (I am not saying this is the correct approach, but this was the trend). Nowadays companies rely heavily on open source and employ software developers almost entirely to apply duct tape on core technologies they get for free. This leads to several “undesired” consequences:
Companies rely completely on open source code bases that their developers usually do not understand, and whose roadmaps they don’t generally control. There are exceptions, of course, but a common company rationale I’ve faced is the following, “if I have a free open source technology that ‘kind of’ does the job for me, why investing in core technologies paying high salaries to an A-team of developers to build it when I can have a junior developer ‘duct tape’ the open source project for me?”
This leads me to the second undesired consequence of open source code, unknown vulnerabilities and low-quality code. Current software projects rely heavily in open source libraries, package managers and containers. But if my developers do not understand and control the code they are using, how would they know if a library they use has a vulnerability, a bug, or is inefficient? There have been a lot of cases in which this problem has led to significant hacks and scary moments. A good way of preventing it? Be sure that at least someone in your team has studied and understands how the open source project you are using works, and what dependencies it has from other code bases and libraries.
(Copy-pasting stackoverflow || following Github's repo readme file || “quick start” tutorial) != understanding a code base
And what about developer’s motivation and salaries? More and more we see software developers and engineers doing non-gratifying duct-taping work during office hours and then doing gratifying work on core technologies during the night for a salary way lower than deserved.“This leads to an interesting vicious circle: given that people choose to work on core technologies for free, no company is investing in those technologies. The underinvestment means that the core technologies are often unfinished, lacking quality, have a lot of rough edges, bugs, etc. That, in turn, creates need for duct tape and thus proliferation of duct-taping jobs”.
This is something EVERYONE has experienced: open source technologies you bet on for your system that are discontinued (for instance, when the main contributor finds a more rewarding and higher-paying job leaving him with less free time and motivation to continue its development); projects where you try to find a library by any means (even if it is outdated or low performant) because you are too lazy to write a simple set of functions from scratch yourself; so on and so forth. I myself have tried to start several open source projects to build technologies I needed, but because of the low traction of the project and my lack of free time I have always had to abandon.
Giving some light to the darkness
You may be wondering, what can we do to fix all this? Let me share with you my view in the matter:
If a company needs the development of a specific core technology, they should initially invest in its development itself. Then, if this technology proves to be of value for the community, and the project gets enough traction, they can open source it and delegate its development to the community. This ensures three things: high quality code, a “clear” roadmap, and a potential long-term support from companies and community. Good examples of this? Kubernetes (Google) or Envoy (Twilio).
Contributors of open source projects should not solely be formed by hobbyists, they should also include professional developers in companies payrolls to ensure their quality. Everyone knows that projects are potentially more successful if you have skin in the game. Consequently, companies should have some skin in the game of open source development. Thus, if no professional developers were contributing anymore to an open source projects it would be a clear sign that, at least from a professional point of view, the project is not valuable anymore for the corporate community, and it should therefore not be maintained anymore (not worth the effort). This would be equivalent to the natural selection of open source projects, only the high quality and stronger ones (well-backed) would survive.
And what would professional open source positions do for the workforce? More highly motivated developers and engineers working in core technologies and doing a job they enjoy. And for the industry? A fair distribution of wealth. There is a great amount of excellent developers in the wild duct-taping things for a low salary while building high impact projects in their spare time. Projects that other developers with high salaries and big pockets use without even giving their fathers the recognition they deserve.
Open source is great, but we can make it greater. Some of the solutions and trends discussed above are already being introduced in the open source ecosystem to fix its dar side. Nonetheless, this is an open discussion, and I don’t expect to be right, but I would love to know what the rest of the software community think about it.