Lime School

Free and Open Source

Emil Sayahi
Sandra Dunstan-Hoover
AP English Language and Composition
21 February 2020

Free and Open Source

  There was a major row in the technology sector recently that led to a lot of debate and thinking on the current software development paradigm. The Actix web Rust-language framework’s author and maintainer, Nikolay Kim, quit following a series of disputes over the usage of the ‘unsafe’ keyword, saying, “I am done with open source.” If you didn’t follow any of that, let me explain.
  The world runs on open source software. It’s code that’s freely available to view, edit, and redistribute, allowing anyone to contribute to a project. These teams of wildly diverse and unknown developers are brought together by a project maintainer, whose job is to take a look at all the offshoots made by various people, and to decide whether or not to incorporate them into the main branch of the project. Being a project maintainer is difficult and stressful. You’re the unpaid boss of unpaid employees who have no connection to you whatsoever, trying to push their code into your project to make a name for themselves.
  This desperation makes for disagreement that can border on contempt, where stressed maintainers have to argue with contributors who strongly feel their changes ought to be made. Often the view of the maintainer and the contributors differ, which could frustrate a maintainer if the project was theirs to begin with, as Kim’s was.
  The “free” in “free and open source” is often taken to mean “not paid for.” That’s a terrible way of looking at that phrase; firstly, “open source” would already entail “not paid for,” so that’d just be redundant. Secondly, just come on, there’s a whole bigger picture you’re missing.
  When a programmer makes something and shows it to the world, they’re proud of it. They’re a sculptor who’d just built a marble statue that would make them think, “By Jove!” and they just had to share it with the world. This artistic freedom is what “free” means. But, it’s a mindset that makes collaboration difficult. How can you have a team that can’t even agree on a goal? It’d be like if dozens of parents just showed up at your door one day and each of them had a different idea for how to raise your kid. It’s chaotic and competitive.
  So, when I look at the hot primordial soup bubbling away, and I step toward it to take a better look, I see tiny battles where some remain victorious and some cede to the boil. The amber glow brings up a sweat in me—a fear of success, where if my software ever catches on it won’t be mine anymore, and I’ll have to either belong to it, or quit.
  This blog is running on some old, decrepit software, Jekyll, that was the belle of the ball back in the day. I’ve been working on a replacement, called WDHAN, that’ll hopefully take off with others looking to solve the same problems I’ve been having, and so far I’ve been largely unsuccessful. My software’s buggy, unstable, erratic and unpredictable. It fails at the simplest of tasks, but it gets better. As I toil harder, putting in more hours, it grows more worthy of my love, and though it stumbles as it walks, I can’t help but marvel in its first steps.
  Now, sure, my code isn’t my baby, but it sure feels like it! In fact, I’m certain I love it more than I could love any child. Anyway, here’s my point: a team can’t exist with competition. That’s how marriages fail and childhoods get ruined. Also that’s how software dies. I think I’m done here. Good day, and code safe, and don’t get in a car accident.


Share this: