If you’re an avid reader of the blog (and come on, who isn’t?), you’ll know that I’ve been maintaining a snap for Nextcloud since Nextcloud came into existence. Originally, though, that snap wasn’t called “nextcloud”, it was called “nextcloud-kyrofa”. My original goal was that I would bootstrap the snap for them, and then they’d take it over when they were ready. I hosted the code as a personal project on GitHub. Once the Nextcloud Box looked like a certainty, though, Jos and I talked about transferring things over to Nextcloud– both the code as well as the snap in the store, so we could call it “nextcloud” and rip my nick off the end.
Ultimately they were on board, but they asked that I continue maintaining it, which was fine with me because I had since fallen in love with it and began using it myself. So I ended up maintaining the Nextcloud snap with the code living in the Nextcloud GitHub org.
That has worked fine for years, but I’m posting today to explain why it no longer works, and why the snap’s code is amicably moving away from the Nextcloud org to one that I fully control.
What happened?
Nextcloud has gotten quite popular, and various pieces of it have attracted a number of contributors, which is wonderful. They are a very welcoming community, and I have found myself at odds with their open-by-default practices. I’ll admit I’m a bit of a grumpy old man, but allow me to explain.
The Nextcloud org has a very low barrier to entry. Essentially, if you contribute anything at all to any of the projects in the org, you’re added to the org. It’s their org, and it’s cool to be able to show that badge on your GitHub profile etc., so I can see how such a process encourages the growth of the community. As of this writing there are 619 people in that org.
Here’s the problem, though: the base role for the Nextcloud org is write access. That means that over 600 people have write access to any of the over-200 repositories in the Nextcloud org. Various Nextcloud apps, utilities, and yes, the snap. Over 600 people that I don’t know have write access to my project. Even as an admin of the project, GitHub seemingly provides no way for me to override the org’s base role. In my humble opinion, while I understand the desire to have an open community, this is poor opsec, and it makes me uncomfortable.
So protect your branches!
Those familiar with GitHub will suggest that I protect my branches. I do that on my personal projects, you can bet I do that were I have collaborators (like here). Sadly, that’s really the only level of protection that GitHub offers. My CI system leans heavily on tags, and anyone in the org can delete them or make them point to another commit. Write access provides quite a bit of access. Even protected branches provide only a single layer of protection. I’m human, after all. If I forget to protect a release branch, it’s game over. Not everyone signs their commits (by the way, you should sign your commits).
And this goes beyond the code, too. There have been numerous times where some random community member will run rampant over my issues without any communication, creating labels and applying them willy nilly. I hate to be ungrateful, but I have a system for things like that. Instead of being helpful, it creates more work for me.
Web of trust
My trust is earned, not granted by default. I like to invite individuals that have earned that trust to join the team that maintains a particular project. It leads to a much smaller community than Nextcloud’s approach, but that community is built on trust as opposed to random contributions to a completely different project. I don’t mean to imply that one approach is objectively better than the other– they serve different purposes.
Snaps automatically update. As a result, the people installing the Nextcloud snap are willingly ceding control of and responsibility for maintaining and updating their Nextcloud stack to the snap maintainers. They are putting their trust in us– in me– and I take that very seriously. If I then allow people I don’t trust to have write access to the snap, do I really deserve that trust? I think not. So I’m taking action.
What’s the plan?
It’s simple: with Nextcloud’s blessing, the Nextcloud snap has moved to the nextcloud-snap org on GitHub, which I own. Now I can promise that the only people with access are the people who have earned my trust. Nothing should change in the day-to-day maintenance of the snap, and GitHub is forwarding traffic from the old URL for those of you who have it cloned (just update your remotes when you get a chance).
As always, I appreciate your support and your trust, and I will do everything in my power to retain it. I look forward to continuing to work with you from our new location!