M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
I was just a teenager when I got involved in the open source community. I remember talking with an old bearded guy once about how this new organization, GNU, is going to change everything. Over the years, I mucked around with a number of different OSS tools and operating systems, got excited when symmetric multiprocessing came to BSD, screwed around with Linux boot and root disks, and had become both engaged and enthralled with the new community that had developed around Unix over the years. That same spirit was simultaneously shared outside of the Unix world, too. Apple user groups met frequently to share new programs we were working on with our ][c’s, and later our ][gs’s and Macs, exchange new shareware (which we actually paid for, because the authors deserved it), and to buy stacks of floppies of the latest fonts or system disks. We often demoed our new inventions, shared and exchanged the source code to our BBS systems, games, or anything else we were working on, and made the agendas of our user groups community efforts to teach and understand the awful protocols, APIs, and compilers we had at the time. This was my first experience with open source. Maybe it was not yours, although I hope yours was just as positive.
It wasn’t open source that people were excited about, and we didn’t really even call it open source at first. It was computer science in general. Computer science was a brand new world of discovery for many of us, and open source was merely the bi-product of natural curiosity and the desire to share knowledge and collaborate. You could call it hacking, but at the time we didn’t know what the hell we were doing, or what to call it. The environment, at the time, was positive, open, and supportive; words that, unfortunately, you probably wouldn’t associate with open source today. You could split hairs and call this the “computing” or “hacking” community, but at the time all of these things were intertwined, and you couldn’t tease them apart without destroying them all: perhaps that’s what went wrong, eventually we did.
Over the last decade, the open source movement has been in a slow migration from people doing hard work to a mixture including a large non-developer or non-contributer user base, and much of that base comes with a sense of entitlement. No, it wasn’t always like that, but it has been moving in that direction for a while. The writing was on the wall from the late 1990s to early 2000s, after Linus Torvalds helped to transform his community into what, in my opinion, had become a toxic environment for years, fueled by intellectual elitism and a perverse sense of do-it-yourselfism. This community demotivated and disparaged developers for years, and it just wasn’t worth it to contribute to his project at a certain point. He wasn’t the only one, unfortunately; the Perl community, which had significant overlap with the Linux community, and much likely to Larry Wall’s dismay, seemed to have fallen in lock-step with this toxic sense of elitism, devolving into the same. Having spent a lot of time in the Perl community myself, I had to eventually abandon the language not because of the usefulness of Perl, but because of the awful fan club that had built around it. While we had open exchange of knowledge and enthusiasm in the 80s, the 90s brought something new to the community: the curmudgeon.
I can only imagine how it must feel to be thrust into the community for the first time at this critical point of negativity, where you are told to “fix it yourself”, disparaged for asking a question, or argued with about your own ideas. It certainly must have been enough to make the “curmudgeon” the status quo for many, and in fact many will tell you that, “this is the way it’s always been”, but have no real idea about how it really used to be.
Over time, and into present day, the open source community somehow devolved into two disproportionate parts: a small core of developers who still share the enthusiasm I’m talking about and start a new project loving what they’re doing, and the rest of the community that 1. does not contribute any useful code 2. makes demands, arguments, or disparages the project 3. considers that to be their contribution. The result is inevitable, and has played out over and over again: the developer either becomes exhausted and burned out trying to take care of his or her undeserving user base, or the developer eventually becomes such a curmudgeon that they push away their user base, and are either viewed as an apathetic jerk, or they actually become an apathetic jerk. Every developer (unless they’re lucky) has, at some point, looked at page after page of open issues on their project, and wondered why they’re the only person working on any solutions to them. There’s only one conclusion to draw: Open source is incredibly broken. The cavalry isn’t coming. Call it laziness, call it the human condition, this isn’t how things are supposed to be.
No one person, of course, is to blame for the toxicity in the open source community today. If I were to conduct an autopsy on it, I’d say the community has eroded because open source was only ever a bi-product, and not the philosophy that many youngsters today are touting it as. The deep drive to discover, learn, and share is the real mindset that backed open source in the beginning, and no matter how much you believe in fairness, licensing, copyleft, security, or other peripheral movements, you can’t fully participate in open source unless you have those three things engrained into you: that’s the philosophy to adopt; open source merely follows naturally after that. You completely miss the point of open source unless you have a strong, selfless drive to learn and share knowledge. The problem is, it’s the people who don’t share that enthusiasm who are making demands of those who do.
The philosophy that much of the community is holding fast to today isn’t the same philosophy that we shared back in the 80s, when the community got into full swing, and a big part of that is probably because much of the community is too young to remember what it was like. It wasn’t about forcing other people to conform to your belief system of open source through means of licensing (or boycotting); it was about creating something to share; your own ideas through code, and sharing them with others who had the same thirst for knowledge. Code is a language, and people were much freer to express themselves in it than they are today. People didn’t steal each other’s ideas, because there was such a strong impetus to come up with your own original ones. I watched the iOS jailbreak community self-destruct over this: even inside inner-circles, you had those who were discovering and sharing, and those who were just media whoring, stealing source code, and contributed little to the effort in the end.
Licensing was thought to fix this, but it never did. The GPL started with good intentions: to be welcoming (and even to try and evangelize) those who didn’t share the belief system of those within the community, by offering tasty treats but making them come into the kitchen first. More often than not, unfortunately, the GPL has been used to as more of a political tool, “we believe in open and free sharing of knowledge… but only if you buy into our belief system”. That’s a far cry from the original community, who would’ve given you the shirt off their back, and licensed everything BSD or MIT. It was never about control, and those who try to control people today usually don’t have the enthusiasm for community that originally pushed that. What we ended up with, as a result of licensing, was a community where a majority of people today do not share in our belief system, and that’s a big part of what’s wrong with it.
What we are left with in the open source community are vain philosophies that have no substance behind them anymore. For example, the philosophy that “we need open source so we can make sure your software is secure”; a cruel irony in that those who say this don’t have much experience with vulnerability research. Those who do are saying the exact opposite, “everything is open source if you try hard enough”; they’re in it for the challenge, not to be spoon fed, and often times I can glean more from your object code than is obvious in your source code. Thank goodness bash was open source, it only took us twenty years to discover Shellshock, not to mention the almost weekly barrage of critical OpenSSL vulnerabilities. Let’s not forget TrueCrypt, which the community was incapable of auditing themselves and had to pool enough money to hire somebody to do it. Security depends much less on open source and much more on financial resources today. Sad fact.
In the same vein, there are many who take the philosophy of not running anything on their Mac that isn’t open sourced, except of course for half of their operating system, which is not, oh and Little Snitch, and just one or two other tools. Maybe Photoshop because GIMP still sucks. It’s hard to have strong convictions when they’re based on the bi-product of a value system that no longer exists. Many fit this mold, where they believe some of the old tenets of open source, but have no idea why. Even if you do run exclusively open source software, have you bothered auditing it? Have you read the entire source tree of the Linux kernel or of Firefox? Because it only takes one obscure line of code to turn it all to dust. You’d better get on that.
I am writing with tongue-in-cheek, of course. Source code is, naturally, beneficial for a number of things, in particular learning how to write better code. This is something, however, that the current open source community isn’t all that interested in (writing code). The reality of the situation today is this: because the community has degraded so much, you no longer need everybody looking at your source code to make it better or secure, you only need a few select qualified individuals. Those qualified individuals (the now 1%) are also typically the last people to look at your source code, because of how toxic the community has become. That leaves the other 99% to demand new features, tell you how your software should have been designed, submit twenty issues about line spacing, send you makefiles you don’t want, and argue about code semantics – all without contributing a single line of code to the project. This will thoroughly drain your resources as a developer, and should that 1% ever come along, you’ll be too much of a curmudgeon to listen to them. Instead, what devs need to do is learn to ignore the 99% and focus on getting that 1% to actually see your code. That 99% is a drain on your resources and morale, and is not what would be considered a traditional part of the open source community.
This article isn’t to chastise the open source community today: I believe we can do better; I’ve seen it do better. I know there are many who don’t fall into this description of selfish, unproductive, and entitled. Those of you who still feel the way I do are the only ones who can affect change. I’m not so sure the current open source community can be saved; the only way to save it may be to start a new community… one of devs who still have the same motivations that fueled computing as a whole some decades ago.
So I have decided not to write any more open source software for now, because the community we have today isn’t really even the open source community. The community today isn’t about sharing or discovery; it’s about people being cheap and demanding free services from you – something F/OSS was never about. That’s not how we started out, and I hope that’s not where we end up. Instead, what I’m going to do is create my own community. I’m calling it “peer source”. All of my new projects are going to become private repos, and anyone else that either I know personally or that someone can vouch for, who’s laying down code and working in this community can have access to them on request, whether they just want to look at it, learn from it, or if they want to audit it, I don’t care. I don’t plan on using any GPL code in my projects, as I believe the system it’s pandering to is now broken. My code is only going to be available to the people who actually work in this community, are productive, actively share knowledge, and collaborate. GitLab allows you to do this at no cost, whereas GitHub does not. You can open as many private repos as you like on GitLab, and give as many people as you like read-only access (or full contributor access). The rest of the community can download binaries, and have the satisfaction that there is accountability on some level, just not to them. Those working in real dev communities, who are qualified to audit and comment on code, will continue to have access.
Open source was never intended to be “user friendly”; it’s a working class; it’s a cooperative. If you could be fired for being unproductive in open source, the community would be a lot smaller than it is today. There is definitely a place for users and their demands, however that’s not inside the community (unless they’re also contributing devs); the community, as in practicing any art form, is vulnerable; you wouldn’t sit and criticize a painter while they’re still painting their piece. The user base needs to be moved outside of the artistic realm and into the museum, where your software is on display. The developers doing good work need to stick together in the inner circles of the community, and cling to others who share the same values to discover, to learn, and to share, all for the sake of bettering computer science. Let users be users. Let hackers be hackers. Only those with the same desire to discover, learn, and share knowledge need apply.
M | T | W | T | F | S | S |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |