Brendan Gregg tells a tale from 2005:
This is the story of the most unbelievable demo I’ve been given in world of open source. You can’t make this stuff up.
I don’t want to ruin it, so I’ll just say that it’s not unbelievable in the way you might think it’s unbelievable.
Due to concerns over control of user information, multiple volunteers have resigned from Freenode to found Libera Chat. This FAQ notes:
What it appears to come down to, is that Andrew Lee is attempting to essentially take over the network by drowning staff in lawyers.
It’s fun seeing the proliferation of TODO comments over time on these bastions of open source. One not-surprising (but still unfortunate) trend: they all pretty much move up and to the right 📈, but a few have had some dramatic reversals 📉 at certain points in time. Go had a crazy month in April 2018 & TypeScript’s TODOs exploded in the Spring of 2018.
Brett Cannon, who is a Python core developer (and a tall, snarky Canadian):
I felt it was time to do another blog post to directly address the issue of entitlement by some open source users which is hurting open source, both for themselves and for others. I want to get the point across that open source maintainers owe you quite literally nothing when it comes to their open source code, and treating them poorly is unethical. And to me, this is the underlying social contract of open source. (emphasis added)
You should read the entire post, especially if you want to learn which programming language (having nothing to do with snakes) that has Brett’s attention. But I’d be remiss not to pull quote this gift of a pull quote from the end:
Every commit of open source code should be viewed as an independent gift from the maintainer that they happened to leave on their front yard for others to enjoy if they so desire; treating them as a means to and for their open source code is unethical.
Raj Dutt, CEO and co-founder of Grafana Labs:
Our company has always tried to balance the “value creation” of open source and community with the “value capture” of our monetization strategy. The choice of license is a key pillar of this strategy, and is something that we’ve deliberated on extensively since the company began.
Over the last few years, we’ve watched closely as almost every at-scale open source company that we admire (such as Elastic, Redis Labs, MongoDB, Timescale, Cockroach Labs, and many others) has evolved their license regime. In almost all of these cases, the result has been a move to a non-OSI-approved source-available license.
We have spent the first months of 2021 having sometimes contentious but always healthy internal debates over this topic, and today we are announcing a change of our own.
Ensuring we maintain these freedoms for our community is a big priority for us. While AGPL doesn’t “protect” us to the same degree as other licenses (such as the SSPL), we feel that it strikes the right balance. Being open source will always be at the core of who we are, and we believe that adopting AGPLv3 allows our community and users to by and large have the same freedoms that they have enjoyed since our inception.
Read the entire post for more details on what is being re-licensed, what isn’t, and what it all means. They also have a Q&A on their blog answering other common questions and concerns.
Let’s face it: Calendly and other scheduling tools are awesome. It made our lives massively easier. We’re using it for business meetings, seminars, yoga classes and even calls with our families. However, most tools are very limited in terms of control and customisations. That’s where Calendso comes in. Self-hosted or hosted by us. White-label by design. API-driven and ready to be deployed on your own domain. Full control of your events and data. Calendso is to Calendly what GitLab is to GitHub.
We’ve been happy Calendly users for years, but I do like the idea of white-labeling and hosting on our own domain. Calendso is built with Next, React, Tailwind, & Prisma.
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.
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.
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.
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.
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. 💯
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.
Guido van Rossum:
I decided that retirement was boring and have joined the Developer Division at Microsoft. To do what? Too many options to say! But it’ll make using Python better for sure (and not just on Windows :-). There’s lots of open source here. Watch this space.
Late last year Guido left Dropbox to head into retirement. Apparently “retirement was boring.” I’m curious to see how coming out of retirement changes things at the steering level of Python.
We talked mid last year with Brett Cannon about Python’s new governance and core team. I don’t recall their plan accounting for the possibility for their BDFL to come back from retirement. 😱
I’m sure whatever is to come for Python with Guido being back, it’ll be a net positive.
There are plenty of metrics you can track—stars, forks, pull requests (PRs), merge requests (MRs), contributor counts, etc.—but more data doesn’t necessarily mean clearer insights. I’ve previously shared my skepticism about the value of these surface-level metrics, especially when assessing an open source project’s health and sustainability.
In this article, I propose two second-order metrics to track, measure, and continually optimize to build a strong, self-sustaining open source community
Those two metrics? Breakdowns of code reviewers and leaderboards of different community interactions. (He also explains why. Worth a read.)
Anaconda CEO (and Practical AI guest) Peter Wang:
I am excited to announce the Anaconda Dividend Program, which formalizes our commitment to direct a portion of our revenue to open-source projects that help advance innovation in data science. We are launching the program in partnership with NumFOCUS, and will kick off with a seed donation of $10,000, as well as an additional 10% of single-user Commercial Edition subscription revenue through the end of this year. Going forward, we will fund the dividend with at least 1% of our revenue in 2021, with a minimum of $25,000 committed for the year.
We’ve been beating the successful-businesses-that-thrive-in-large-part-due-to-open-source-software-should-set-aside-revenues-to-support-those-projects drum for years now, so it’s exciting to see forward-looking companies like Anaconda step up and do just that. More like this! 🙏
Thanks to Alex Williams over at The New Stack for doing a great write up remembering Dan Kohn and the tremendous mark he has left on open source and Cloud Native. Of course Dan had help along the way, but by-and-large the CNCF and “cloud native” as we know it are the direct result of Dan’s vision and leadership.
Thank you Dan. You will be missed.
We knew little in 2016 about what Dan was up to but we soon got a hint. The CNCF was already established but what it represented was still a bit unclear. If anything, Dan was a businessman and a computer scientist. He knew the economic importance of at-scale computing and the technical complexity that made it so fascinating.
The technical community was ready for someone like Dan — they needed help. Open source cloud native projects were growing but the resources were essential to keep progress moving. He was there to make sure the work got done that technologists should not have to do: Building awareness, supporting the publicity of new projects and perhaps most of all, smoothly running the conferences.