NPM Bug

Our first reading was about a problematic NPM bug where Linux file permissions were being altered, that was written as an issue by the GitHub user Crunkle on February 22, 2018. The best way to describe the seriousness of the bug was the description that “People experiencing this bug will likely have to fully reinstall their system due to this update.” Yeah that’s a pretty big problem. Other than the bug itself, there was a lot of backlash in the comments of this issue because NPM made the 5.7.0 seem like a release as opposed to a pre-release which meant some users got confused and put this very broken code on production systems, which would then crash because of the issues. This set off a bit of a war in the comments. There were people calling each other incompetent because of their production upgrading procedures. Then there were people being very upset at and sometimes rude to the NPM devs for allowing such a big bug to be allowed in and making 5.7.0 look like a release. It got bad enough that the main collaborators locked the issue thread to collaborators. The issue was eventually fixed and 5.7.1 was released and 5.7.0 taken down.

There are some things to be learned from this situation. It seems like the NPM developers need to be more clear about communicating which updates are releases and what is a pre-release. It seems their communication needs to be improved. Though it also seems to be that people got a little too overzealous and contributed more fuel to the fire instead of helping to resolve the situation. The NPM team seems to have handled this the best they could at the time. It’s hard to handle large amounts of backlash and according to the timestamps they handled the matter relatively quickly.

Why Digital Infrastructure is Crumbling and FOSS is Struggling

Our second reading was Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure by Nadia Eghbal published on July 14, 2016, from the beginning up to page 77. This is a fascinating read. The author’s main point is that most of the software we know today is built upon open source software. Everything involves software now from out computers and smart-phones to doing regular tasks such as buying things online, paying bills, or going to the doctor. Every business has some sort of tech infrastructure. The overwhelming majority of this software uses something that is open source. Eghbal emphasizes the importance of FOSS as an essential part of our digital infrastructure. She also described the practical aspects of FOSS. Because the software is free developers are able to build applications faster and for a fraction of the cost when proprietary software was dominant. This makes is easier to for startups because of the dramatically reduced cost. It is also useful for education as the tools are free to use for teaching. As such it is essential to keep those open source projects going. However these FOSS projects are often not seen often because like roads and electricity most people don’t think about who’s managing it when they are using roads to drive their car or turning on a light switch. These projects need funding and contributors to keep going. Eghbal explains how some projects are large enough to get money through companies sponsoring them and through donations. Though some projects are able to sustain themselves through enterprise support or special features they can sell. Besides money there is the problem of getting enough contributors.

The author covers that in open source’s early days there were a roughly an equal amount of people contributing to open source projects as there were those using it. This made the projects sustainable. In recent years there has been a dramatic increase in users and a decrease in people able to contribute. The author also talks about “magpie developers” who want to contribute to the new shiny projects as opposed to the older projects who need help also. Eghbal also describes a problem where some people in the open source community believe that there is a decrease in people able to contributre substantial code to the project. These developers are less experienced and so can’t contribute much code and/or create more work for the other contributors. This is where I disagree a bit. Although there are definitely people who are less experienced, it’s important to realize that all of us were at that stage at some point and to be compassionate about that. The key is to make sure a project is a welcoming community and helps to encourage those new developers to hone their skills and so will contribute better and better code as time goes on. This problem can be exacerbated by people who just see themselves as users and so only demand things of the project team. This doesn’t mean that those who are trying to contribute should be valued so much less so because their skills are not coding. Projects need to invest in new developers.

The other problem often has to do with depending on the one or two maintainers to be the sole administrative force of the project while doing a lot of the coding. It seems that there are quite a few projects need to have better organization. What doesn’t help is that those who start the project are often the people who just want to code not be a project manager. This can be where people who don’t code or who don’t code that much can help out with open source.

Overall I really enjoyed this read about issues in FOSS and the wider effects of that although I didn’t quite agree with everything the author said.