Popular Rockchip SBC distro in limbo after maintainer burns out

Recently Joshua Riek posted he's dropping off from GitHub. If you haven't heard of him, he's one of the few reasons working with Linux on Rockchip SBCs is so much easier today than it was just a few years ago.

His Ubuntu Rockchip distribution is built for Ubuntu 22 and 24, and they've been maybe the most popular and stable way to run Ubuntu on Rockchip devices.

So popular, in fact, that manufacturers who use Rockchip, like Turing Pi, build their own official images on top of Joshua's.

XKCD Dependencies

Now, if you're reminded of XKCD #2347, yeah, I am too.

Basically, Rockchip, a company valued in the billions of dollars, can't be bothered to help SBC makers like Turing Pi with an official Linux distribution, so Turing Pi turned to Joshua's project and actually worked with him to try to get their hardware working better with it.

But from what I've heard, some other vendors—and I'm guessing a lot of individuals in the community—didn't treat Joshua with the respect that he deserves or with financial support in return for the help that he gave.

Sure, there are also other community distros like Armbian, but when I think back to like five or so years ago before Joshua's distro and before Armbian was his mainstream, it was sometimes impossible to get Linux running stable on many Rockchip boards.

They usually support older LTS Linux kernels like 5.10 now and 6.1, and their RK3588 might get support for 6.11 soon.

But that's all besides the point.

Today I wanted to talk a little bit about the maker-taker problem in open source.

The Maker-Taker Problem in Open Source

Specifically, why Joshua is stepping away from his extremely popular distro and why this is happening more broadly in many areas of the open source ecosystem.

Because this problem with open source has only gotten worse, while the stakes get higher.

And just thinking back a few years, there's been Elasticsearch who changed their licensing after Amazon repackaged their products and sold hosting for them on AWS.

Red Hat took CentOS and changed the way it was packaged so it was much more difficult for downstream users to use that as their server OS.

Redis Labs changed Redis's license to make it harder for people to host it and sell that hosting.

Those are commercial enterprises that saw people reproductizing their own offerings and making money off of them. This problem reached a crescendo as we've witnessed Matt Mullenweg drag the Wordpress community through the mud this year in response to some WP Engine trademark issues that would've been better handled in court.

I'm not going to get deep into it, but it was a similar problem.

There are people who make these products and the people who invest a lot of time and resources and people who might not put as much time and resources into making, but they take from it and earn a lot of money off of it.

And the thing is that in all these cases, the license is the most important part for someone who's philosophical about open source or free software.

Sometimes these companies will even change their licensing.

And I think that's a pretty shady way of going about things.

If you license something free open source software with GPL or with some license that gives users freedoms, to attract developers to your ecosystem, then you start taking away those freedoms over time, that's pretty shady.

On the flip side, most of my software is either MIT or GPL licensed.

I do a lot of work to build my software. People can take the work that I do and build a product that makes 20-40x the amount of money I'm ever going to make off of them.

Is that fair?

I mean, for me, I don't care that much, but for a lot of people, they do care.

And a lot of people don't have the safeguards that I've built up over the years to prevent the burnout.

And, you know, that licensing side is one thing, but the open source community, I think is even more important, the community that you foster around your projects.

Community

And my open source philosophy and my introduction to free software came out of Drupal, an open source CMS that's written in PHP.

It's still very popular. It's a lot different today than it was when I found out about it back when it was version 5.

The leader of Drupal, Dries Buytaert, wrote Drupal and he still is the BDFL.

He works at a company called Acquia. I worked there for a short time, too; but they don't own Drupal.

It's a little bit different approach than a lot of other open source software projects.

Drupal is a community first.

There used to be a saying—I don't know how true this is anymore because I'm not as active in that community—but it was come for the code, stay for the community.

For a lot of software developers who are deep into the FOSS or open source ecosystem, it depends on where you came into it from.

For those of us in Drupal land, we came and saw this community of people working together to build up this project.

And we all found ways to monetize it for our own goals.

There are tons of companies that still exist that they do full-time Drupal development, and all of them are making tons of money off of it. Some of them contribute back more, some of them contribute back less.

But in Drupal, that community was part of the core part of what made you someone who did Drupal stuff. Many of the Drupal-centric company leadership were invested in the community.

Drupal has over the years built up this idea of contributions giving a company or individuals more prominence within the community, to the point where it's incentivized through the tooling and development process.

But that's not the only reason I think that Drupal has succeeded where a lot of other projects have floundered.

You have a central company that is not necessarily in control of it, Acquia, but they also do have a lot of the people that are in the project's central kind of command structure.

But they all delegate that responsibility, to people in other companies, even some individuals working independently. Sure there's a board, there are political structures in place now... some of that can get annoying.

But it's worked over the years, it's different than a lot of other communities.

A lot more wealth is created outside of just the core people who built Drupal or maintain it today.

And that's not a bad thing in the Drupal community—that's a good thing.

My own personal software philosophy has always been, if I can build something that's cool, and someone else can take that and do something way cooler and way better and make tons of money off of it?

That's awesome.

I created more wealth in the world than I could have made personally—as long as I have food on my table, as long as I have mental health.

For me, I've built up safeguards to prevent burnout.

Plus, I have a YouTube channel and my books to supplement the income I get through Patreon and GitHub Sponsors.

But I'm always happy to see people build off my stuff.

Now, I don't want people stealing things that I don't release with an open source license, like the text of my blog or my video content—even though that happens too.

But anything I release as open source, I'm glad when people take that and build off of it.

But some of this is tangential.

Be liberal with your 'No'

The point I want to make today is some communities—especially communities that revolve around hardware like SBCs or electronics projects—sometimes people have roadblocks to that mentality that we had in Drupal that leads to a sustainable environment of contribution and support for each other.

Sometimes people are kind of prone to wearing themselves out and burning themselves out, especially if you don't have a community or don't have people around you that are watching for warning signs and trying to get you out of a rut like that.

And you know, I really hope that Joshua can come back and get the financial and emotional support he needs to thrive in his development process. For my part, I sponsored him on GitHub since I've benefitted from his work in the past.

Maybe we can get that Ubuntu project back up and running someday.

But I don't blame him for a second if he never comes back at all. That would be fine with me.

It can be harsh, especially coming from me who I maintain a ton of open source projects.

But for my own protection, I usually come in pretty hot and heavy and I close issues; I use the stale bot, and I say no, probably more often than yes. And if something if a thread gets angry or discussion gets heated, I just ignore it.

It's not worth my time.

I wrote in 2020:

Be liberal with your no, and be judicious with your yes.

For me, that led to a ton of freedom to pursue my YouTube career. And also still maintain all the little open source projects that I want to use for my own good.

And if other people benefit from them, that's great.

If you don't like the way that I do it, fork it.

Comments

Good writing Jeff, but what you didn't insist on is end-user support and operational costs. Most of us OSS developers don't care if a company takes the work for free and makes money out of it, after all it's a proof of success like any other.

However when, like Joshua, your project consists in making a crappy device start to work, we all know that not everything is smooth at once, and there are likely a lot of expectations from end users who just bought a board on the advice from a friend saying "just buy this, there's this guy that made it work perfectly". But the end user having spent $100 on an SBC discovering his favorite thing not working that well can be unhappy of their purchase and don't even know that the guy over there has no relation with the board nor chip vendor and is doing that work for free. There's likely a lot of (mostly involuntary) abuse, but even beyond the abuse, when you're in front of the support cannon, your mood can progressively degrade because you quickly spend more time dealing with problems than making things great, and your own perception of your work is that it's crap and causes lots of trouble.

And on this point, board vendors that point to just developer's work and tend to advertise it as a fantastic solution are in part responsible of the burnout, because they implicitly create higher expectation from their customers than they should be (all that to sell their boards).

And finally there are operational costs. This project is no exception. Once free hosted solutions are no longer available, the developer either needs to start paying for some storage and revisit their whole release process to adapt to something new, or start paying for enterprise-level services on the existing platform. Given that Joshua is directly responsible for a small part of Rockchip sales and of the board vendors' revenue, the least they could do would be to pay for a higher-grade GitHub service to host his work under better conditions, at least for the time it takes to find a more suitable solution if needed. I don't count much on Rockchip to provide any help, it doesn't seem to belong to their DNA to make their products work with standard operating systems. They just heavily patch outdated kernels until they seem to work well enough for devices to sell.

End users tend to ignore all of this ("my free service costs me money", "my work is done on spare time", "sorry for the bugs I don't have access to the specs", "I'm not the one working on the BSP kernel you're using" etc). If at least vendors pointing to this work could remind it all the time, it would help.

There's likely a lot of (mostly involuntary) abuse, but even beyond the abuse, when you're in front of the support cannon, your mood can progressively degrade because you quickly spend more time dealing with problems than making things great, and your own perception of your work is that it's crap and causes lots of trouble.

Truer words have never been spoken! :(