marisa's "blog"

Today we released Rustlings 2.0. There's some interesting things in this release:

  • Exercises are now indexed by name, not by file name. This means that where previously you had to input a long path with rustlings run exercises/primitive_types/, you can now shorten it to rustlings run primitive_types1
  • rustlings watch will now require the user to delete a comment called // I AM NOT DONE to proceed, even when the exercise compiles or tests. Many of our exercises encourage the user to try out multiple different solutions, which was not possible to do before, since you had to move out of watch and manually verify the exercise using run. rustlings verify is also affected by this, but rustlings run is not.
  • There is a new way to interact with hints. Hints are not at the end of the file anymore, instead, you can view the hint(s) for a given exercise using rustlings hint exerciseName. Multiple people were having problems with hints being visible due to their screen heights or their autoformatters not playing nice, which is why it was refactored.
  • Rustlings now self-checks for the existence of rustc before running, in case you somehow installed Rustlings without having rustc.

A massive thanks to Roberto Vidal for pairing with me on some of these issues and helping push this out.

Significance of a breaking change

This release isn't all that special in terms of feature density. We haven't added or removed any exercises, but the reason we've decided to release a new major version is because we introduced what we believe are breaking changes.

Rust projects usually try to abide by a standard known as SemVer, which attempts to quantify the long headache of software versioning into something that makes sense in people's heads. The short version of it is:

  • Bug fixes –> Increment Patch (0.0.1 to 0.0.2)
  • Feature additions and enhancements that are backwards compatible –> Increment Minor (0.0.1 to 0.1.0)
  • Features, Deletions, Enhancements that are backwards incompatible –> Increment Major (0.0.1 to 1.0.0)

The latter of those three cases includes breaking changes, which means changes that make the new API of your software incompatible with how it was used before.

The problem with our changes is that, say, refactoring the hint system (aka introducing the rustlings hint command) technically doesn't produce a breaking change, as we're only adding a feature to our API (the Rustlings CLI). What we're getting at is the limits of a technical specification such as SemVer, which fails to address the human-centered side of software.

Admittedly, and in defense of SemVer, dealing with humans is really hard, and I'm not criticizing for that, but for software like Rustlings, which thousands of people use for learning Rust, we can't purely rely on a technical spec for releases.

Releasing software for humans

How then are we going to solve this dilemma? It seems like we'll have to throw some existing conventions out of the window and make our own. What we came up with is more or less specifically aimed at Rustlings, and it's partly based off SemVer, and partly based off what our intuition tells us:

  • Bug fixes –> Increment Patch
  • Feature additions, or backwards incompatible changes that only affect a small part of the exercises (changing one exercise or changing one category of them) –> Increment Minor
  • Backwards incompatible changes in the CLI source or changes that modify all exercises –> Increment Major

When I say “based off our intuition” here, what I mean is that we took into account how people using Rustlings will perceive these changes. The important thing to take into account is that the way most people use Rustlings is very limited – they download it, do a bunch of exercises, and then it likely sits on their hard drive untouched for a long time. This isn't a bad thing, and it does mean we can get away with introducing breaking changes on a smaller scale as long as it affects only a specific subsystem. Not many people are going to do an exercise, wait a year, update Rustlings, and then do the exact same exercise again.


So what's the actual takeaway from this? I guess it's that if you're designing software for teaching people, or just people that aren't software developers, consider thinking about their perspective when using your software before you blindly adhere to SemVer. Again, not saying SemVer is bad, but there have been some people that seem to believe adhering to SemVer is the best thing you can do in any situation, to which I disagree. I believe knowing who you're making software for is the best thing you can do in any situation.

I logged onto GitHub today, and got greeted with this lovely message:

As many might have heard, GitHub started enforcing the stricter regulations set by the US government with regards to international sanctions recently. What this actually means is unclear to even the people who are directly affected by it, as GitHub only offers this page as a meager explanation. From what I can tell, I've lost access to all of my private repositories, as well as the ability to create new ones. Also, the site seems to randomly slow down sometimes, and I get weird error messages sometimes, indicating a 500 HTTP response, but those are fixed when I try to perform the action again.

I don't really expect this to change anything with regards to the monopoly GitHub posesses in the version control and code collaboration space, as the majority of people affected seem to be from Iran, and not from its primary user base, the US. I believe I've only been affected because I accessed my repositories from Cuba once, which they must have found out by checking my IP history. Needless to say, since GitHub provides a possiblity to file an appeal, I'm filing one unless they start asking me for my personal information. Not that I'll be using GitHub much anyways, but it would be nice for employability reasons.

Update: They require you to submit your ID and photographic evidence

UPDATE (8/25/2019): This afternoon, I got completely suspended from my GitHub accounts. The reasons (and implications) of this are something I don't want to discuss here, but I've spent the last month(s) moving all of my stuff elsewhere and won't be using GitHub any longer.

Should I be moving from GitHub?

The only realistic alternative to being on GitHub, that is, moving from GitHub explicitly as a political response to their collaboration with the US regime, is hosting your own Git server. I'd recommend it to anyone, just as I'd recommend moving off Slack (who have pulled the same kind of shit) and Discord (who apparently collaborate directly with the Department of Homeland Security). Even if you're a big project, now is the time when you should be evaluating whether you want to prioritize being on GitHub over categorically excluding entire countries from collaboration. This situation isn't going to get better, it's going to get worse, and one of the most thoughtful things you could do as an Open Source developer is to keep that in mind.


There's a fair amount of Git hosting & collaboration alternatives these days, and I've tried some of them:

  • GitLab: This is what I currently use. It's a bit bloated, but if you have enough money to shell out for a VPS with 8 gigs of RAM, it works just fine and has enough features to replace at least one of your existing external tools.
  • Phabricator: It's clearly designed for larger teams, but if you're willing to get your hands dirty in some PHP hosting configuration, it's a good alternative and has about the same amount of features as GitLab, plus the design is (IMO) better (supports HG and CVS, too!).
  • BitBucket: Never used it, but it's hosted in the US, and it's Atlassisan. Make up your own mind.
  • Gitea/Gogs: Also haven't used it, but seems nice. Might lack a few features?

If there's any self-hosted alternatives that I'm missing, please recommend them to me on Twitter!

(It's best to read this blog post after reading Steve Klabnik's The culture war at the heart of open source and What comes after “open source”, in my opinion)

I think most of us once thought that Free Software was great. Then, as we gradually became more aware that most of the originators of the Free Software movement are huge pieces of shit, we steered more towards Open Source as a morally and logically just model of software distribution. Over time, I've become more and more disillusioned with both movements and over the past months I've finally decided that I'm not going to continue publishing open source or Free Software unless it's a collaborative project or unless absolutely required. Let me elaborate a bit on why.

What's wrong with Free Software?

Free Software, in its essence, is a utopian philosophy centered around the same notion of “freedom” that you would commonly hear from people that reply to any mainstream American politician on Twitter. It's this idealistic perception of reality that at first enthralls a lot of people. Who wouldn't want to live in a world where all software is free to give away and to use as long as you make it publicly available under the same terms? Where everyone enjoys the same benefits? Everyone, surely!

It's a nice pipe dream, but we live in a world with harsh inequalities, including in our sector of work. To start, not everyone is able to work on software in their off hours. This is something completely unheard of in most other fields of work. Especially in a market economy, the thought of someone putting hundreds of hours into a product and then offering it for free to the rest of the world is very atypical. At one point, some of these people came together and decided that distributing a product, irrelevant of how much labor went into it, for free should be the new standard. Consistent with their notion of “freedom”, they also decided that if you use and modify the product, you should have to put up your derivation under the same terms. There's clearly two different fronts covered here:

  1. The usage or distribution of the software. This is what copyleft licenses are all about, ensuring that the people who use the software follow a certain set of rules, most of the time centered around modification and attribution.
  2. The production of the software. This isn't as apparent as its distribution, so most people just take it as a given, which is why the Free Software movement makes no attempts at fixing that. The immense amount of labor that goes into producing a software artifact is usually ignored, and instead some abstract notion of “rights” that usually don't benefit the developer are enforced.

Developers who aren't in as privileged a situation as those people who only install Free Software on their computers will realize that if we wanted to make sure that our “rights” are protected and our interests represented, we would encompass the entire software development lifecycle, not only its distribution.

What's wrong with Open Source?

Did you think the ignorance of Free Software was bad? Cool, Open Source takes what little rights were given to the developer and throws them away. The most prevalent OSS license, MIT, gives all rights to the consumer. What if that consumer turns out to be manufacturing drones that kill children in Yemen? Doesn't matter, and even if it did, you don't have any rights to enforce it (and even if you did, their lawyers are better than any you can muster). Keep in mind that a copyleft license would at least require Lockheed and Raytheon to publish a little sidenote saying “ah by the way here's the source code for the library we used”, which is so much better, right?

Free Software was born from idealistic libertarianism, and Open Source was born from realistic liberalism because Free Software didn't give companies enough rights.

What are the alternatives?

Being conscious of whose interests you're serving is the first step. Most solutions to this will not work if there's no broad awareness of the underlying problem. Steve Klabnik has theorized a number of solutions, but I don't necessarily agree with them (aside from there probably never being enough popular consensus around them). What we have is an unjust social structure that effectively holds itself up by exploiting people's labor. As time has proven with other, similar social structures, the only useful way to get rid of them is not via reform.

Frankly, this issue requires a lot more thinking upon to come up with any even potentially viable solutions, so until then, here's what I'll do:

  • Not publish any more open source software unless it's required by an employer or similar
  • If I do somehow end up publishing open source software, license it under a License Zero license

I don't think a new license is the answer. Companies can easily bypass licenses by sheer force of intimidation, and the legal system certainly isn't set up to defend workers' entitlement to their labor. Rather, we need to rethink our approach to balancing production and distribution of software. I'm not sure how to do that, but I'm rather confident that this will ultimately happen if we build a movement around it.

What about paying maintainers? Paying maintainers won't work on any scale that's larger than, say, the 300 biggest open source projects. GitHub Sponsors is largely designed to work on a user-to-user basis, which makes it identical to crowdfunding (plus they're letting the people with the most social capital in first lol). Ultimately, it's trying to reform a system that was created to be unequal from the very beginning.

So are you saying if I maintain a large open source project, I should just make it private?

I also maintain a rather large open source project, and I'm not planning to take that private. Although if you feel prepared to face an incredible amount of backlash, but show how much the industry relies on institutionalized exploitation, go for it! I'd envy you.

I disagree!

If you have tangible points that go beyond disagreeing with “the software industry, Free Software and Open Source are built upon exploitation of developers”, feel free to put them forward. Or don't.

And remember: Complacency is complicity :)