This week Alexander Neumann takes Jerod on a tour of Restic, the world-class backup solution that’s fast, secure, and cross-platform. We discuss why he created Restic in the first place, how (and why you should) you use it, some of its more interesting technical bits, lessons learned over the years building and maintaining a community, and more of course.
This week we’re talking with Ben Johnson. Ben is known for his work on BoltDB, his work in open source, and as a freelance Go developer. Late January when Ben open sourced his newest project Litestream in the readme he shared how the project was open source, but not open for contribution. His reason was to protect his mental health and the long term viability of the project. On this episode we talk with Ben about what that means, his thoughts on mental health and burnout in open source, choosing a license, and the details behind Litestream - a standalone streaming replication tool for SQLite.
This week Adam talks with Spencer Kimball, CEO and Co-founder of Cockroach Labs — makers of CockroachDB an open source cloud-native distributed SQL database. Cockroach Labs recently raised $160 million dollars on a $2 billion dollar valuation. In this episode, Spencer shares his journey in open source, startups and entrepreneurship, and what they’re doing to build CockroachCloud to meet the needs of applications that require massive scale and ultra-resilience.
We are on a mission to make working for an open source project a legitimate alternative to a career working for a for-profit corporation. To achieve our goal, we must remove friction between projects, the communities who support them, and the corporations who depend on their work (and can fund them)
Their entire premise is that companies would invest more in open source if it were easier for them to do so. So, they’re making it easier by introducing “funds”, which companies can set up and then give to one place instead of a dozen (or more) projects separately. And they’ve already gotten the ball rolling:
Over the last year, we’ve been quietly establishing a number of Funds, which have turned into great examples of what happens when you solve the barriers between corporations and open source projects.
This week we’re talking about the future of freeCodeCamp with Quincy Larson and what it’s taken to build it into the non-profit unicorn that it is. They’re expanding their Python section into a full-blown data science curriculum and they’ve launched a $150,000 fundraiser to make it happen with 100% dollar-for-dollar matching up to the first $150,000 thanks to Darrell Silver.
As you may know, we’re big fans of Quincy and the work being done at freeCodeCamp, so if you want to back their efforts as well, learn more and donate.
Airbnb, Amazon, Instagram, Netflix, Tiktok, Spotify, Trello, Whatsapp, Youtube, you get the picture. It includes links to source code and demos, the tech stack, and GitHub star count for each entry.
The the OpenForum Europe think tank conducted a study to highlight the potential benefit of embracing open source:
To analyze the impact of open source software in terms of economics, OFE engaged economists who had prior experience illustrating the effect of technology in tangible terms.
Here’s how they calculated said benefit:
the economists estimated that in 2018 there were at least 260,000 open source contributors in the EU. Together they produced a volume of code equivalent to the full-time work of 16,000 developers. In terms of economics, these contributions stood between €65 billion ($77.8 billion) and €95 billion ($113.7 billion).
Based on this, the OFE report concluded that even an increase of 10% could potentially increase the EU’s GDP by almost €100 billion ($120 billion) per year.
Are these numbers 100% accurate? No. Are they provocative when considering open source impact? I think so.
In theory, trademarks protect freedom. In practice, trademarks prevent abuse.
Neither the terms “Open Source” nor “Free Software” are themselves trademarked, which unfortunately allows anyone to use them to describe anything – companies regularly exploit this to undermine public understanding of the freedoms which the words originally conveyed. This is why we are using trademarks early and often in Lightmeter — to avoid problems for users and ourselves later on.
Daniel Stenberg and tfw your open source code (curl) is used by a malicious hacker (seemingly, it’s hard to tell for sure) to attack someone and effectively destroy their business (and life, by extension) and then said victim turns around and threatens your life in a completely unprovoked email. Tragic in every sense. Sorry you had endure this, Daniel.
This week we’re talking about the recent falling out between Elastic and AWS around the relicensing of Elasticsearch and Kibana. Like many in the community, we have been watching this very closely.
Here’s the tldr for context. On January 21st, Elastic posted a blog post sharing their concerns with Amazon/AWS misleading and confusing the community, saying “They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse.” This lead them to relicense Elasticsearch and Kibana with a dual license, a proprietary license and the Sever Side Public License (SSPL). AWS responded two days later stating that they are “stepping up for a truly open source Elasticsearch,” and shared their plans to create and maintain forks of Elasticsearch and Kibana based on the latest ALv2-licensed codebases.
There’s a ton of detail and nuance beneath the surface, so we invited a handful of folks on the show to share their perspective. On today’s show you’ll hear from: Adam Jacob (co-founder and board member of Chef), Heather Meeker (open-source lawyer and the author of the SSPL license), Manish Jain (founder and CTO at Dgraph Labs), Paul Dix (co-founder and CTO at InfluxDB), VM (Vicky) Brasseur (open source & free software business strategist), and Markus Stenqvist (everyday web dev from Sweden).
Daniel Stenberg answers critics who believe curl shouldn’t be hosted on GitHub (for various reasons) by asking himself the question: what happens if GitHub “takes the ball and goes home”?
No matter which service we use, there’s always a risk that they will turn off the light one day and not come back – or just change the rules or licensing terms that would prevent us from staying there. We cannot avoid that risk. But we can make sure that we’re smart about it, have a contingency plan or at least an idea of what to do when that day comes.
Whether or not you agree with Daniel’s GitHub-related conclusions, this statement is 💯% true and we should all be doing similar analyses before adopting any 3rd-party offering.
This week we’re talking about open source industrial machines. We’re joined by Marcin Jakubowski from Open Source Ecology where they’re developing open source industrial machines that can be made for a fraction of commercial costs, and they’re sharing their designs online for free. The goal is to create an efficient open source economy that increases innovation through open collaboration. We talk about what it takes to build a civilization from scratch, the Open Building Institute and their Eco-Building Toolkit, the right to repair movement, DIY maker culture, and how Marcin plans to build 10,000 micro factories worldwide where anyone can come and make.
Maintainer burden is real.
As the author of BoltDB, I found that accepting and maintaining third party patches contributed to my burn out and I eventually archived the project. … Small contributions typically required hours of my time to properly test and validate them.
I am grateful for community involvement, bug reports, & feature requests. I do not wish to come off as anything but welcoming, however, I’ve made the decision to keep this project closed to contributions for my own mental health and long term viability of the project.
The simple solution is for GitHub to allow repo owners to restrict which users can interact with the pull requests feature for a given repo. This would be a great usage of the teams feature already in place.
This week we’re talking with Gregory Kurtzer about Rocky Linux. Greg is the founder of the CentOS project, which recently shifted its strategy and has the Linux community scrambling. Rocky Linux aims to continue where the CentOS project left off — to provide a free and open source community-driven enterprise grade Linux operating system. We discuss the history of the CentOS project, how it fell under Red Hat’s control, the recent shift in Red Hat’s strategy with CentOS, and how Rocky Linux is designed to be 100% bug-for-bug compatible with Red Hat Enterprise Linux.
Drupal creator Dries Buytaert with lots of reason to celebrate:
On January 15, 2001, exactly 20 years ago, I released Drupal 1.0.0 into the world. I was a 22 years old, and just finished college. At the time, I had no idea that Drupal would someday power 1 in 35 websites, and impact so many people globally.
Quite the accomplishment. Congrats to Dries and the entire Drupal community!
In this post, he also shares why he’s still working on the project and details 3 birthday wishes for Drupal:
- Never stop evolving
- Continue our growing focus on ease-of-use
- Economic systems to sustain and scale Open Source
Those sound like noble wishes to me. 💯
Today we welcome Mike Pennisi into our Maintainer Spotlight. This is a special flavor of The Changelog where we go deep into a maintainer’s story. Mike is the maintainer of JSHint which, since its creation in 2011, was encumbered by a license that made it very hard for legally-conscious teams to use the project. The license was the widely-used MIT Expat license, but it included one additional clause: “The Software shall be used for Good, not Evil.” Because of this clause, many teams could not use JSHint.
Today’s episode with Mike covers the full gamut of JSHint’s journey and how non-free licensing can poison the well of free software.
What do you do when you make a living typing on a keyboard, but you can no longer do that for more than a few minutes at a time? Switch careers?! Not Josh Comeau. He decided to learn from others who have come before him and develop his own solution for coding without his hands. Spoiler Alert: he uses weird noises and some fancy eye tracking tech.
On this episode Josh tells us all about the fascinating system he developed, how it changed his perspective on work & life, and where he’s going from here. Plus we mix in some CSS & JS chat along the way.
Tailwind CSS creator Adam Wathan joins Jerod, Nick, & Feross for an in-depth discussion of his trending utility-first CSS framework. We cover why everyone complains about CSS, how Tailwind began and how it gained popularity, how developers use with Tailwind and integrate it into their workflows, and how Adam has managed to build a business around the project. Thanks, Bette Midler!
Until yesterday, I was still clinging to a few shreds of romantic optimism about open source software businesses. Mapbox is the protagonist of a story I’ve told myself and others countless times. It’s a seductive tale about the incredible, counterintuitive concept of the “open core” business model for software companies.
We’ve discussed the challenges with open core on many occasions (this episode of The Changelog on Nextcloud immediately comes to mind), but most of those conversations center around the tension of balancing commercial and open source interests. This Mapbox open core story, on the other hand, has a different villain:
Today, we’re gathered here on the internet to mourn the death of the open core business model. We’re here to tell stories of the before-times, to reminisce about how smart we thought we were. We went against consensus, and we were wrong. Because, open core is dead.
Cloud killed open core.
It was covered in fantastic detail on the Changelog #414 but now it’s real. Gitter now works natively with Matrix.
Joe Morrison on how OpenStreetMap has quietly become a core piece of open source infrastructure:
OpenStreetMap is now at the center of an unholy alliance of the world’s largest and wealthiest technology companies. The most valuable companies in the world are treating OSM as critical infrastructure for some of the most-used software ever written.
What a success story. Do you think it can be repeated?
Envoy’s open source community is amazing. I looked the other day, and at least on GitHub, just from a code contribution perspective, we’re almost at 600 contributors. Which for a fairly low-level C++ project… that is freakin’ incredible. It just blows my mind. And then you look at all of the vertical products and all these other things that are built on top…
There are many factors that contributed to this success, but one thing I did early on stands out as the most important thing I could’ve done. In this post I share my secret with you.
Running an open source project is more than just writing code. Jussi Pakkanen says “…most of all work has to do with something else,” which if you listen to The Changelog, our Maintainer Spotlight series, or Request for Commits then you know this all too well.
This places additional requirements to project maintainers that are often not talked about. In this post we’ll briefly go over nine distinct phases each with a different hat one might have to wear. These can be split into two stages based on the lifetime and popularity of the project.