A quick post by Drew DeVault on why he believes software must be robust, reliable, stable, and simple.
It’s certainly interesting to ponder how to store data for as long as you possibly can, which Drew highlights very well. But I really enjoyed the questions at the end on “actually storing data forever”…
Let’s say you’ve managed to keep your data around. But will you still know how to interpret that data in the future? Is it in a file format which requires specialized software to use? Will that software still be relevant in the future? Is that software open-source, so you can update it yourself? Will it still compile and run correctly on newer operating systems and hardware? Will the storage medium still be compatible with new computers?
In short, I use git branches very rarely, preferring to work on my local master branch almost every time. When I want to work on multiple tasks in the same repository (i.e. often), I just… work on all of them on master. I waste no time creating a new branch, or switching to another branch to change contexts; I just start writing code and committing changes, all directly on master, intermixing different workstreams freely. This reduces my startup time to zero, both for starting new tasks and revisiting old work.
If the blog post ended here, you might think Drew is crazy. But he goes on to explain how he uses rebase to clean things up before pushing upstream.
I enjoy hanging out on master quite a bit, myself. However, when I’m ready to take on something “big” or “gnarly” I don’t hesitate to
git checkout -b and work from there.
As I got started writing open source software, I generally preferred the MIT license. I actually made fun of the “copyleft” GPL licenses, on the grounds that they are less free. I still hold this opinion today: the GPL license is less free than the MIT license - but today, I believe this in a good way.
As someone who has spent tens of thousands of hours developing free software, Drew’s thoughts on these matters are well considered. After reading this, I had to ask myself why I still prefer MIT. Ultimately, I think him and I differ on motivation. He states:
I give people free software because I want them to reciprocate with the same.
I give people free software and I want them to reciprocate with the same. However, I don’t do it because I want them to do it. I do it because I want to give the world a gift. Full stop. What about you?
Have you ever seen someone write something to the effect of “I would use Go, but I need generics”? Perhaps we can infer from this that many of the people who are pining after generics in Go are not, in fact, Go users.
The inertia of “what I’m used to” comes to a violent stop when they try to use Go. People affected by this frustration interpret it as a problem with Go, that Go is missing some crucial feature - such as generics. But this lack of features is itself a feature, not a bug.
A year ago Drew Devault laid out his future plans and path to sustainably working on open source full-time. Today, those plans have been realized.
I don’t want to make grandiose promises right away, but I’m confident that increasing my commitment to open source to this degree is going to have a major impact on my projects. For now, my primary focus is sr.ht: its paid users make up the majority of the funding.
Drew goes on to say how he’s making this leap before the needed income is actually there, so if you dig what he’s up to, you can play a part in making his choice a success.
I need to clarify that despite choosing to work full-time on these projects, my income is going to be negative for a while. I have enough savings and income now that I feel comfortable making the leap, and I plan on working my ass off before my runway ends to earn the additional subscriptions to sr.ht and donations to fosspay et al that will make this decision sustainable in the long term.
Drew Devault, announcing “sir hat” (or however you want to refer to it)
For those who are new, let me explain what makes sr.ht special. It provides many of the trimmings you’re used to from sites like GitHub, Gitlab, BitBucket, and so on, including git repository hosting, bug tracking software, CI, wikis, and so on. However, the sr.ht model is different from these projects - where many forges attempt to replicate GitHub’s success with a thinly veiled clone of the GitHub UI and workflow, sr.ht is fundamentally different in its approach.
This has folks pretty excited. But what’s all the hubbub about? Well, in addition to being 100% free and open source…
The flagship product from the software suite is it’s CI platform, which:
is easily the most capable continuous integration system available today. It’s so powerful that I’ve been working with multiple Linux distributions on bringing them onboard because it’s the only platform which can scale to the automation needs of an entire Linux distribution.
There’s always a potential for hyperbole when the creator is describing their creation, but I’m convinced this is at the very least worth checking out. It might even make for a great episode of The Changelog…
In the wake of Microsoft’s acquisition of GitHub, the murmurs of replacing GitHub with something decentralized have been getting louder. In this article, Drew Devault points out that email-based git workflows are A Thing and one that works quite well.
In particular, this blog post is a direct response to forge-net (formerly known as GitPub). They want to federate and decentralize git using ActivityPub, the same technology leveraged by Mastodon and PeerTube. But get this: git is already federated and decentralized!
After all these years is email still the web’s killer app?