Alex Ellis:

Yesterday, Docker sent an email to any Docker Hub user who had created an “organisation”, telling them their account will be deleted including all images, if they do not upgrade to a paid team plan. The email contained a link to a tersely written PDF (since, silently edited) which was missing many important details which caused significant anxiety and additional work for open source maintainers.

He goes on to explain the problem in great details. Btw, Alex is no Docker hater. He has a long history of using and supporting the tech. He goes on to say:

Open Source has a funding problem, and Docker was born in Open Source. We the community were their king makers, and now that they’re turning over significant revenue, they are only too ready to forget their roots.

This decision seems myopic. There are other image hosting options, one of them even shares (inspired?) half of DockerHub’s name… Oh, and here’s our open invitation to the folks at Docker to come on the pod.

An open-source knowledge-based community software. You can use it quickly to build Q&A community for your products, customers, teams, and more.

It looks like a lot of work has been put into this, with more cool stuff coming (integrations, gamification).

Filippo Valsorda:

Last May I left my job on the Go team at Google to experiment with more sustainable paths for open-source maintainers. I held on to my various maintainer hats (Go cryptography, transparency tooling, age, mkcert, yubikey-agent…), iterated on the model since September, and I’m happy to report that I am now a full-time independent open-source maintainer.

People like Filippo are still (unfortunately) the exception, not the rule. BUT! I’ll celebrate every time an open source maintainer makes it to the promised land, hopefully paving the way for others to follow after.

I’m sharing details about my progress to hopefully popularize the model, and eventually help other maintainers adopt it, although I’m not quite ready to recommend anyone else drop everything to try this just yet.

Tyler Cipriani read “‘Did you miss my comments or what?’ Understanding Toxicity in Open Source Discussions,” and learned about entitlement:

The term is new (to me), but the paper renders a familiar scene, “The author is usually visibly upset about not being able to use the tool, often complaining about wasted time.”

The situation is all-too-common and exhausting. And when it happens over-and-over, maintainers give up.

It made me wonder: why have I never seen “entitlement” in a code of conduct?

Good question…

Thomas Depierre, writing about the concept of the Software Supply Chain in the context of open source development:

We are not suppliers. All the people writing and maintaining these projects, we are not suppliers. We do not have a business relationship with all these organisations. We are volunteers, writing code and putting it online under these Licences. And yes, we put it online for people to use them. But we do not get anything from it.

He goes on to discuss how, importantly, licenses such as the MIT point this out (in all caps):

If you use this, I owe you nothing. At all. We have no relationship. I put this up online on the condition that if you use it, all the risks are on you… So all your Software Supply Chain ideas? You are not buying from a supplier, you are a raccoon digging through dumpsters for free code. So I would advise you to put these rules in the same dumpster. And remember. I am not a supplier.

That raccoon line reminds me of a now-ancient meme you might still enjoy…

Tony Parker writing on Swift’s blog:

When Swift began life as an open source project, we wanted to open not just the language itself, but the ecosystem around it. Foundation has been instrumental in the success of decades of software and has been an integral part of the Swift developer experience from the beginning, and we knew it had to be included in the open source offering.

Historically, Apple’s open source efforts have varied in just how open they are when it comes to community. On that topic, this is an uplifting bit of prose:

Open source projects are at their best when the community of users can participate and become a community of developers. A new, open contribution process will be available to enable all developers to contribute new API to Foundation.

This new Foundation project is slated to launch on GitHub in 2023.

As the old saying goes, imitation is the sincerest form of flattery. In the software world, an open source alternative is the sincerest form of imitation. Well, Retool (a Changelog sponsor) can consider themselves flattered, because Openblocks sets out to do openly what they’ve been doing proprietarily. Here’s why:

It’s cumbersome to create a single app. You had to design user interfaces, write code in multiple languages and frameworks, and understand how all of that code works together.

Low-code/No-code platforms are fast to get started with but quickly become unmaintainable and inflexible. This creates more problems than it solves.

Retool-like solutions are great for their simplicity and flexibility, but they can also be limited in different ways compared to frameworks like React/Vue.

Openblocks wants to take a step forward. More specifically, Openblocks is

• An all-in-one IDE to create internal or customer-facing apps.
• A place to create, build and share building blocks of web applications.
• A domain-specific language that UI-configurable block is the first-class citizen.

This is so cool! Shout out to Zach Latta (Founder of Hack Club) for giving me a call today to tell me about Sprig — this awesome new Hack Club project is built by teenagers for teenagers.

Sprig is a game console where every user is a creator. It can only be obtained by building a tile-based game in the web-based game editor and shipping it in the community gallery. It’s made by Hack Club.

… Fall of 2022, we are giving a Sprig (valued at over $100 in components alone) to every teenage hacker that successfully shares a game they create in our community gallery.

A couple weeks back, Adam logged some news that linked to githubcopilotinvestigation.com. Well, There’s a new website now: githubcopilotlitigation.com

Matthew Butterick:

By train­ing their AI sys­tems on pub­lic GitHub repos­i­to­ries (though based on their pub­lic state­ments, pos­si­bly much more) we con­tend that the defen­dants have vio­lated the legal rights of a vast num­ber of cre­ators who posted code or other work under cer­tain open-source licenses on GitHub. Which licenses? A set of 11 pop­u­lar open-source licenses that all require attri­bu­tion of the author’s name and copy­right, includ­ing the MIT license, the GPL, and the Apache license.

Is GitHub Copilot an AI parasite trained in the realms of fair use on pub­lic code any­where on the inter­net? Or, is it a much needed automation layer to all the reasons we open source in the first place?

When I first wrote about Copi­lot, I said “I’m not wor­ried about its effects on open source.” In the short term, I’m still not wor­ried. But as I reflected on my own jour­ney through open source—nearly 25 years—I real­ized that I was miss­ing the big­ger pic­ture. After all, open source isn’t a fixed group of peo­ple. It’s an ever-grow­ing, ever-chang­ing col­lec­tive intel­li­gence, con­tin­u­ally being renewed by fresh minds. We set new stan­dards and chal­lenges for each other, and thereby raise our expec­ta­tions for what we can accom­plish.

Amidst this grand alchemy, Copi­lot inter­lopes. Its goal is to arro­gate the energy of open-source to itself. We needn’t delve into Microsoft’s very check­ered his­tory with open source to see Copi­lot for what it is: a par­a­site.

The legal­ity of Copi­lot must be tested before the dam­age to open source becomes irrepara­ble. That’s why I’m suit­ing up.

What are your thoughts on this investigation and “poten­tial law­suit” against GitHub Copi­lot?

MNT Research… is going small for its next project. The MNT Pocket Reform has a seven-inch screen with a clamshell design that, when closed, will be less than five centimeters thick. If its perky purple facade looks a bit retro, that’s no surprise; the Pocket’s inspirations read like a ‘greatest hits’ list of pocketable computers.

They’re taking open source seriously:

MNT’s open-source promise is not limited to an open source operating system or select internal components The Pocket Reform, as with MNT’s full-size Reform laptop, will provide mainboard schematics, 3D models for physical components, and open source drivers, among other things.

Coming soon to a crowd fund near you.

This book is my condensed personal experience in the last 12 years in various projects, communities and roles in Open Source. Including my best practice, tips and a lot of examples and resources.

After 2 years a new edition is here with new stuff and also available on Amazon Kindle.
134 pages about best practices and suggestion about the open source world!

iliana etaoin:

There is a lot of attention on securing “software supply chains.” The usual approach is that you want to try to avoid security issues in your underlying components from impacting customers of your product; and when they do, you want to be able to respond quickly to fix the issue. The people who care about this class of problem are often software companies. The class of components that are most concerning these companies are ones where unpaid hobbyist maintainers wrote something for themselves with no maintenance plan.

This is where the supply chain metaphor — and it is just that, a metaphor — breaks down…

I think we all know this intrinsically, but it’s easy to forget. iliana goes on to describe feelings I’ve heard expressed by a few maintainers recently:

I just want to publish software that I think is neat so that other hobbyists can use and learn from it, and I otherwise want to be left the hell alone. I should be allowed to decide if something I wrote is “done”. The focus on securing the “software supply chain” has made it even more likely that releasing software for others to use will just mean more work for me that I don’t benefit from. I reject the idea that a concept so tenuous can be secured in the first place.

The ideas behind WikiHouse remind me of the conversation we had with Marcin Jakubowski from Open Source Ecology early last year (changelog.fm/428).

Sustainable should be the new normal. Think global, manufacture local. It’s all open source.

Everything is on GitHub (from what I can tell).

Nitasha Tiku writes on The Washington Post:

The only way to escape technology that makes money off your data is by paying for products that don’t, Whittaker says. An alternative to data collection only exists if the community of people who rely on it “kick in a little bit,” she said.

Signal is one of the few successful tech products, like the Firefox browser, led by vociferous critics of Big Tech. The app offers end-to-end encryption on group text, voice and video chat, does not collect or store sensitive information and does not store backups of your data on its servers — a viable alternative to relentless data gathering at the center of tech industry critiques.

In the world of messaging (today), you have behemoths like WhatsApp and iMessage, and they are “backed by some of the richest companies in the world.” And then there’s Signal. It’s run by a nonprofit and pretty much operates as the exact opposite — they are committed to end-to-end encryption, does not collect or store sensitive information, or backups of user data.

This post from Nitasha Tiku on The Washington Post gives a detailed backstory on Meredith Whittaker, former Google manager, and her arrival to Signal as President (and board member since 2020), as well as why Signal “hopes to support itself with small donations from millions of users.”

This post reacting to other people’s reaction to GitLab’s recent free tier changes starts kinda rant-y:

Lots of users expect to get things for free, forever, from for-profit companies that don’t answer to them. Those users contribute almost nothing1 to the bottom line for the for-profit companies, and actively drive up costs for them. Yet, somehow, with no skin in the game, they feel entitled to complain and badmouth the companies because they’re not getting as much value for their monthly contribution of nothing at all.

But it ends with a pretty strong call to build things for ourselves:

Create a business case, get the funding, stand up the infrastructure, and pay people to work on it rather than expecting for-profit companies to prioritize (what you see as) the public good over profit. Whether that’s how things should be or not, it is how they are and that isn’t going to change as long as the only movement in the direction of change is people hectoring for-profit companies to do better.

Curl creator/maintainer Daniel Stenberg is writing a book. It’s (aptly) named: Uncurled

Because of my background and life with Open Source and probably a lot because of the relative success some of my projects have had, I frequently get questions about subjects related to maintaining Open Source. How to run a project and what makes them succeed? For a long time I have been collecting lessons from my life with Open Source into a list of advice for fellow Open Source library hackers. This document is my attempt to convert those thoughts and experiences into words.

I don’t believe it’s finished, but there’s a lot here already! Excited for this and while it’s a free to read GitBook right now, I hope it ends with some kind of physical manifestation.

Good for them (and us)! But what does that mean in practice?

Over the next few months, we’ll be completing the OpenJS Foundation’s incubation program checklist, including transferring the Jest domain, repo, website, and other assets to OpenJS. We’ll also be updating the code of conduct and contributor license agreement.

Additionally, as part of this move, we will be publishing a project charter and creating new governance policies that will document the process for gaining commit access, as well as our leadership selection process.

Next up: React?! A guy can dream…

Supabase CTO Ant Wilson walks through the pros & cons of open sourcing your startup and why he believes the answer to the question in the headline is (probably) “yes”

Open-sourcing Supabase ended up surprising us in many ways. Many people imagine that maintaining your business in public might be burdensome - but the opposite is true. There are many unexpected upsides that have made building Supabase - the product and the company - easier.

While some of this advice comes from our lens as a Dev Tools or PaaS company, most of it will apply to any software company.

Max Howell, creator of Homebrew, has gone back to his notes on brew2 to apply web3 concepts to help “distribute value to open source.” He’s calling this new brew tea.

Tools like Homebrew lie beneath all development tools, assisting developers to actually get development done. We know the graph of all open source, which means we’re uniquely placed to innovate in interesting and exciting ways. This is exactly what tea will do. We’re taking our knowledge of how to make development more efficient and throwing innovations nobody has ever really considered before.

With plans to move the package registry on-chain, Max lays out the numerous benefits due to “inherent benefits of blockchain technology”:

• Packages will be immutable (no more left-pad incidents)
• Packages will always be available (we’ll use decentralized storage)
• Releases will be signed by the maintainers themselves (rather than a middleman you are told you can trust)
• Tools can be built to fundamentally verify the integrity of your app’s open source constitution
• Token can flow through the graph

Max says “token flowing is where things get really interesting,” and goes on to say “with our system people who care about the health of the open source ecosystem buy some token and stake it.”

(Thanks to Omri Gabay for sharing this first in our community Slack)

ZFS has become very portable in recent years of its development, supporting six (6) operating systems: FreeBSD, Illumos, Linux, MacOS, NetBSD, and Windows. But what if you wanted to create a ZPool compatible with all of them? Which options and ZFS features should you choose?

If you haven’t yet, check out The Changelog #475 where I talk with Matt Ahrens (co-founder of the ZFS project) about making the ZFS file system.

All the details of the National Science Foundation’s “big bet” are in the article, but here’s the money quote:

If you are working on an open source project that might benefit from this kind of funding, check it out here. Phase I applications are due May 12, 2022, and Phase II applications are due October 21, 2022.

Bhupesh Varshney:

A lot of folks looking how to get started on open source are given very generic advice on how to approach their first contribution. In this newsletter issue I share one specific actionable item.

His secret tip? Solve static analyzer issues. There, I saved you a click. Unless you’re not sure what he means by that or want his advice on how to actually get that done…

I love this idea by Simon Willison:

I think I’ve come up with a novel hack for the challenge of getting your company to financially support the open source projects that it uses: reach out to the maintainers and offer them generous speaking fees for remote talks to your engineering team.

It won’t work for every person and situation, but we should add it to our arsenal of ways to return economic value back to the maintainers of our open source infrastructure.

The criteria for inclusion is as follows:

1. Its product is strongly based on an open source repo
2. It has a well-known closed-sourced competitor, solving a similar business problem
3. It is a private for-profit company, founded in the last 10 years
4. Its repo has 100+ stars on GitHub

I’m seeing lots of Changelog guests & friends in this awesome list. 😎