💌 This is my mid-week newsletter. Expect another one on Friday.
🚀 Tomorrow, we're kicking off the January cohort of Hype-Free Crypto. Missed this one? Join the next one in February.
👷🏻♀️ Later this month, I will also be teaching the 11th cohort of Future-Proof Real Estate about the technologies and business models that are reshaping our offices and homes. This one is a must for anyone investing, designing, or developing property.
[Post edit: I'm not sure if it's the same person, but this piece mentions a programmer with the same name as a person who was arrested a couple of years ago after "bomb-making equipment" was found in his home. ]
"The developer behind popular open-source NPM libraries 'colors' (aka colors.js on GitHub) and 'faker' (aka 'faker.js' on GitHub) intentionally introduced mischievous commits in them that are impacting thousands of applications relying on these libraries...
...users of popular open-source projects, such as Amazon's Cloud Development Kit (aws-cdk) were left stunned on seeing their applications print gibberish messages on their console....
The colors library receives over 20 million weekly downloads on npm alone and has almost 19,000 projects relying on it."
Let me explain this in plain English. Many (most) software projects rely on pre-existing code snippets to save time. These snippets are called "libraries.". Libraries address many common and recurring needs such as handing user emails and passwords, resizing images, manipulating the size and color of texts, and more. Instead of reinventing multiple wheels each time they build a new project, developers rely on libraries.
One helpful analogy here is musical instruments and samples. When someone sets out to record a new song, they can program or sample their own unique instruments and beats. But they can also rely on a set of existing libraries. This way, they can focus on their cool new song instead of recreating a whole suite of instruments and beats.
But there are a couple of key differences when it comes to computer code. First, code libraries are available on an open-source basis, making them accessible for anyone to use and rely on. Second, code libraries often require maintenance and updates to address bugs and remain compatible. And so, software developers don't just take code from a library; they refer to a library that, in turn, gets frequently updated. The interaction between different code repositories is handled on platforms such as Github.
At best, code libraries create a lot of positive value, enabling millions of people to build things on top of existing foundations — and ensuring these foundations are constantly reinforced and improved. At worse, this creates dependencies that leave large and essential pieces of software at the mercy of a single library and the individual who maintains it. Often, those large projects have no relationship with, or control over, that individual.
The whole system relies on the assumption that individual maintainers will continue to do their job or, at least, not do anything to mess things up. But sometimes, individuals get upset.
That's what happened this week. Marak Squires, the developer of two popular libraries, decided to inject malicious code into them. This resulted in messing up multiple projects that depended on these libraries. Why did Marak do it? Because he got tired of seeing other people profiting off of his free work. From Bleeping Computer:
"The reason behind this mischief on the developer's part appears to be retaliation—against mega-corporations and commercial consumers of open-source projects who extensively rely on cost-free and community-powered software but do not, according to the developer, give back to the community.
In November 2020, Marak [the maintainer] had warned that he will no longer be supporting the big corporations with his "free work" and that commercial entities should consider either forking the projects or compensating the dev with a yearly "six figure" salary.
"Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn't much else to say," the developer previously wrote.
Code repositories such as Github and its subsidiary NPM responded swiftly in order to clean up the mess. As Marak reported on his Twitter feed, these platforms suspended his access to his own projects and reverted his code to the last version that actually worked. Marak added an extra spin to his protest by mentioning Aaron Swartz, a software developer who died while serving time in jail for hacking the MIT library to gain access to academic papers.
This ordeal brings up a few interesting questions:
- Does Marak have the right to change the code in his own project?
- Does Github have the right to prevent him from maintaining his own code and changing the code in order to meet the needs of large corporations? This is particularly pertinent since Microsoft acquired Github in 2018.
- Is there a better way to compensate open source developers (and communities) to prevent such resentment from boiling over in the future?
All three questions also highlight some of the shortcomings of web 2.0, which web3 developers are trying to address. As I mentioned in an earlier piece:
"Web3" is used to describe a new approach to how the internet should run. In our current era (web2 or Web 2.0), a handful of giant companies own most of the data and govern most communication and transactions. This creates three main problems:
1. Users cannot easily leave a platform they don't like (because all their data, relationships, and digital assets are not "portable");
2. This also works in reverse: Users can lose their data, relationship, and digital assets overnight when a platform like Twitter, Facebook, or YouTube decides to shut down their account; and
3. Even in the best of times, users are not compensated for the value they contribute to the platforms they use (e.g., Facebook makes billions off of people posting content for free and clicking on ads, but Facebook users don't get compensated for their contribution).
In other words, the web we have is too centralized, leaving too much power and profits at the hands of a handful of giant companies. Web3 is an umbrella term for various efforts to reshape the web and address these issues. Specifically, these efforts include developing decentralized computing infrastructure that is difficult to censor or shut down and developing protocols that allow users to easily port their "accounts" (identity, data, digital assets) across different apps.'
The Marak Squires ordeal ticks all three boxes. A software developer is disgruntled after (allegedly) not being fairly compensated for the content he contributed to a web platform owned by a giant corporation. The disgruntled developer is prevented from deleting or altering his own code from the platform. And the developer is also prevented from accessing the rest of his projects and data on said platform.
This highlights an important point that most people miss when thinking about NFTs. Non-fungible tokens are not about art, speculation, crime, or whatever else people currently do with them. NFT are about empowering people to own, control, and monetize intellectual property. As I wrote in NFTs and the Future of Work:
"Most people on earth do not create gifs. "Content" is not just Beyonce's new song or the highlight real of yesterday's playoff game. Content is the two lines of code that an engineer somewhere just added to an open-source project. That Slack message your colleague sent you this morning is also content. And of course, the newsletter you sent to your 72 subscribers last week is also content, even if you're not a celebrity.
Can these two lines of code, Slack message, or an email that nobody read be sold just like a work of art? No, because they are not a work of art. But they are work. And so, someone deserves to get paid for them if they end up being useful.
Most humans are either overpaid or underpaid for their work. I am not talking about minimum wages or fair salaries. I am talking about the fact that two employees in the same company can earn the same salary even though one of them contributes much more than the other to the company's overall success. And by "contributing", I don't mean that one employee spends more time at the office than the other; I mean that she comes up with ideas that end up being used by the company — she contributes important building blocks to whatever it is the company is building."
In that article, I also highlighted open-source software as a field in which many contributors are not compensated fairly (or at all) for their contributions, and how NFTs can help:
"Most of the software we use was created by thousands of different people. Some of these people are entrepreneurs, some are employees, and some are volunteers or members of open source communities...
With NFTs and smart contracts, it is now possible to integrate all of the above with a proper compensation mechanism. It is possible to allow every contributor to get paid exactly according to their contribution..."
NFTs can fill an important void. Github and other code repositories can already track which projects rely on which lines of code from which libraries. Github knows which individual contributions are useful and critical. What's missing is a cheap and robust system to enable individual contributors to get paid directly and automatically each time their libraries are used. NFTs and smart contracts can serve as the foundations of such a system.
More broadly, this story highlights the dangers of letting a company like Microsoft control the world's largest repository of open-source code. It is easy to imagine a blockchain-based alternative to Github, and I am sure a few people are already working on one.
Enjoy the rest of your week. 🙏 If you enjoyed this piece, subscribe to my newsletter. If you'd like to dive deeper into the promise and limitations of blockchain technology, check out my Hype-Free Crypto course.
To learn more about open-source communities, check out Nadia Eghbal's wonderful Working in Public
Dror Poleg Newsletter
Join the newsletter to receive the latest updates in your inbox.