Add problems in FLOSS post #1

And two draft posts I've started writing but not finished

content/post/on-knowledge-workers-and-unions.md

@@ -0,0 +1,119 @@
++++
+
+class = "post"
+date = "2019-11-14T19:00:00-05:00"
+tags = ["politics","union","administrator","developer"]
+title = "On Knowledge Workers and Unions"
+description = "or, On unions for developers and aministrators from a Marxist perspective"
+type = "post"
+draft = true
+weight = 1
+
++++
+
+It's been quite a while since I made a post on here, and this one is not about tech itself, but on my opinions, politically-influenced, on Unions and my industry of DevOps. This post is heavily influenced by my own political views. I'm a Marxist - I subscribe to his Labour Theory of Value, his idea of Dialectical and Historical Materialism, and his ideas on the Class Relations of workers (proletarians) and owners (bourgeoisie) along with a few more obscure classes. I'll try to avoid filling this post with excessive leftist jargon in the hopes of not requiring much or any previous knowledge of leftistism, but some may still slip through and I'll try to define them in context. But ultimately I hope this post will inspire some alternative thoughts about unionization and professional relations within our industry to our benefit. I think labour relations are something the "IT Industry" needs to think about broadly as we expand in size, both to avoid selling ourselves short (literally) and repeating the mistakes of the past. I'm sure a lot of this could also be applicable to other fields, but I'm focusing heavily on my own field here, and I will refer to "knowledge workers" to respresent us and a few similar fields more generally and "IT industry" to refer to DevOps (and its two child fields, software development and systems administration) more specifically.
+
+# On Knowledge Workers and Unions
+
+I just finished reading [Erik Dietrich's fantastic post](https://daedtech.com/the-beggar-ceo-and-sucker-culture/) on what he calls the Beggar CEO and Sucker Culture. It draws on a previous post of his, [Defining the Corporate Herirarchy](https://daedtech.com/defining-the-corporate-hierarchy/) itself inspired by [a post by Venkatesh Rao](https://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or-the-office-according-to-the-office/) and the original cartoon by Hugh MacLeod. If you haven't read these posts, I'd definitely recommend reading them - the post by Rao in particular is more a series than a post, is incredibly long, but is incredibly important and has definitely influenced a lot about how I think of corporate culture.
+
+In this article, Dietrich talks about an Ask Abby-style article in which (briefly) a CEO complains that her workers leave after their 9-5 and won't work long hours "like [she] does". And I agree with a lot of Dietrich's points here. But he is careful not to make this "political". He, for his own reasons, keeps the discussion purely in terms of existing Neoliberal Capitalism (the dominant form of Capitalism in the Western core since the early 1980's focused on tax cuts for the rich and "austerity", public service cuts for the working classes) without any class analysis. One commenter noticed this, the aptly-named "Unionist":
+
+>Unionist: More than 2,000 words and not one of them is “union”. That’s the real problem.
+
+The resulting comment chain was a fairly expected debate between a few pro-union (and a few seemingly leftist) commenters, some anti-unionist knowledge workers, and the author himself. One section of the chain struck me in particular:
+
+>Eric Dietrich: I don’t think that collective bargaining is the cure for what ails a high-demand, knowledge work field. Reason being, I don’t think we need to accept the subordination that entails — I see the demand for and cost of software creating a future where we engage in a professional services model, like doctors and lawyers. Those professions don’t need to unionize because they control the game. So should we.
+
+>Eric Boersma: Respectfully, I think this is a place where you’re letting your own skill set cloud your judgement of what’s possible. Everyone cannot just be consultants, dispensing code where it is valuable and proper, because that’s not a model that fits the needs of many or most programmers or businesses. Most programmers are quite bad at selling their own skill sets. Most poorly estimate what they’re capable of providing – many to the positive, some to the negative. Consultation very rarely provides space for effective on-the-job training, putting a higher workload onto individual employees to continue to grow their skills in useful directions throughout their career. Additionally, it’s telling that your two examples, lawyers and doctors, have significant and difficult profession entrance exams which gate people who are not capable of doing the job effectively from being able to claim the title as well as grueling early-career workloads.
+
+>The vast majority of doctors do not work for themselves. The vast majority of lawyers do not work for themselves. The vast majority of developers will never work for themselves; all three of those groups can use the power that collective bargaining provides to effectively improve their work conditions. Swearing off unionization as a means of professional advancement is like becoming a programmer and swearing that you’re never going to use TCP/IP because you’ve heard bad things about it. You’re taking tools out of your toolbox before ever giving them a shot, and ignoring them even when they’re clearly the best tool for the job you’re trying to accomplish.
+
+Dietrich's opinion reflects what I see as a trend in the IT industry away from meta-analysis of our own employment in a leftist lense. I think this is a very flawed, but common, understanding, and he uses an also-common-and-flawed comparison to two other well-discussed knowledge worker careers: doctors and lawyers. Boersma points out several quick examples of these flaws, but I think this deserves a more in-depth breakdown, because the issue of unions in the IT industry, and of knowledge workers more broadly, is woefully un-discussed and becomes more relevant with every new member joining the field.
+
+## On "Knowledge Workers" - Doctors and Lawyers, a brief history
+
+The first place to start would be on the comparison made between IT workers and two other extremely-well-cited knowledge worker fields: doctors and lawyers. It is extremely common to mention these two careers when discussing wages, compensation, and other employment-related matters. I hope for their sake that readers are generally aware of these two professions, if not the specifics of each, so I'll avoid discussing them in detail. But the comparisons involved when discussing these two professions almost invariably comes down to a few common elements that both professions share, at least in the Anglosphere (the "English-speaking West" of the US, UK, and the nations of the British Commonwealth, including my own Canada):
+
+1. Doctors and Lawyers are generally considered to be "high class" jobs worthy of aspiration to.
+
+1. Doctors and Lawyers, especially Senior (10+ years experience) members, are generally very well-paid, making "upper-middle-class wages".
+
+1. Doctors and Lawyers generally work very long hours, upwards of 60+ per week.
+
+1. Doctors and Lawyers are both extremely well-educated, requiring many years of schooling, practical "grunt-work" experience, as well as professional certification.
+
+If you're an IT professional, or an Engineer, or an Architect, or one of several other knowledge fields, looking at this list, you'll probably notice that these traits are also generally shared by us. And this is not something I see as a flaw in Dietrich's argument. It's absolutely true that these professions, collectively, are something entirely different from what many would call "blue-collar" labour, the proletarians of Marxist thought. And throught the development of leftist though, a name was created to describe these workers: the "Professional and Managerial Class" (PMC). Normal western non-leftist though commonly calls this the "Middle Class", but that is a term devoid of meaningful analysis and hence I will not use it. I also exclude the "managerial" element of this class in my discussion here, partly due to the influence of Rao's opinions on corporate culture in the 21st centure, and also because to lump them together would hinder the analysis.
+
+As the world has moved further into the 21st century, knowledge workers have come to dominate the discussions of the future of labour. This is after all what someone is implying when they say, usually to a worker who's job has been automated by machinery, "go back to school to get an education and a 'better job'". Education is an important component of PMC careers. But usually when this is said, the person saying it is *not* implying that the target should be one of these two specific jobs. Why is that?
+
+First and foremost, being "high class" jobs really means little, and under capitalism usually means "very well-paid". So why are these two careers very well paid?
+
+The most common answer is generally the other two points: "they work very long hours and deserve the high pay", and "they had to spend a lot of time and, without public-paid post-secondary education, money training in the job". But this doesn't tell the whole story.
+
+The important thing is their *union*.
+
+But, you may ask, what union? I don't mean "unions" as is traditionally thought of them here. What I mean is their professional standards organizations.
+
+Doctors have medical schools and the AMA, ACP, etc.. Lawyers have law schools and the "bar" of their jurisdiction. PEng's have engineering schools and their local societies, in Ontario the OSPC. A similar story is true for almost every other PMC industry (except of course the managers).
+
+These professions all have bodies that, while not focusing primarily, or even at all, on collective bargaining or the proletarian-versus-bourgeoisie element of employment, include an element of certification to the profession. In order to truly call yourself a Lawyer, legally, you must pass the bar. Or pass a medical school exam, followed by a residency. Or write a professional engineering certification. What these bodies do is ensure that these knowledge workers form an insular society, which is gatekept by the existing members of the organization in order to ensure a minimum bar of knowledge before a new member can work professionally.
+
+This, I think, is what fundamentally separates PMC careers from "blue collar" careers like trades or service work, despite trades in particular superficially resembling this. Every one of these careers has a bar that must be crossed.
+
+## On Traditional Unions - the why and how
+
+With the PMC out of the way, we can discuss the main point of unions - their protection of workers from exploitation. All things that are usually associated with unions - collective bargaining for better compensation, workplace standards, protection of members from dismissal - all tie back into this point; they protect workers from exploitation by the ownership class.
+
+The history of unions is long and depressing. Born out of the conditions of coal mines, steel foundries, and Dickensian sweatshops, they sought to organize workers together to fight against their exploitation. They were brutally, violently, suppressed time and again, but kept fighting until they won what are commonly consindered the hallmarks of modern employment: 8(-ish) hour days, fair pay, weekends, workplace health and safety regulations, and a plethora of other things modern workers take for granted.
+
+But Western unions lost much of their power throughout the 20th century, as the protections they won became the norm, and as more dangerous, labourious, and low-skilled work was exported to poorer parts of the world. This culminated, I think, in one of the major blows against unions in modern history: the 1981 Air Traffic Controllers strike, where Ronald Reagan called the ATC union's bluff, and fired the entire union's membership and replaced them.
+
+One of the biggest threats of unions has always been the idea that firing the entire union membership is impossible - if not because they would be easy to replace, then because they could literally occupy the factory, mine, or workplace and prevent others from working. But this was impossible in 1981. How do even 11000 people occupy hundreds of airports, guarded by millitarized law-enforcement officers behind razor-wire fences. It was an exceptional situation for sure, but the ripple effects were wide-reaching.
+
+Union membership has been declining steadily since the 1980's, especially as neoliberalism became the norm. And unions have since developed a very unsavoury reputation - that they "keep bad employees employed", that they simply suck money from members to fund a union elite (a Labour Aristocracy), and that they're generally useless.
+
+But of course, this has never been true and has been said of unions since their earliest days. The fact is unions have been a force for more good than bad, and that fixing these problems with unions is one of building class consciousness and solidarity, not insurmountable considering where unions started. Unions can be powerful if they're well organized, and this is visible even after four decades of attack.
+
+## On the IT Industry's Lack of Organization
+
+Despite them not being "unionized" in the normal sense, knowledge workers are still organized by their certification bodies. And "blue-collar" workers form traditional unions, which ensure all members are treated fairly.
+
+But the IT industry lacks both of these. In fact, for the most part it lacks *any* coherent organization at all. And this is indeed a problem.
+
+First, as a whole the IT industry does not have any sort of professional certification body or specific schooling. There may be optional certs, computer science or engineering courses, and a few professional *societies* like the IETF or the League of Professional System Administrators, but these are not binding organizations. Indeed, a large part of the appeal of the IT industry, especially software development, is that it requires no formal training or education to become a member, allowing those who have self-taught compete with even thir most well-educated colleagues.
+
+Second, despite appearing very much like a traditional trade, the IT industry has almost no collective representation. Indeed, due to the silo'd nature of the field (as is, for instance Engineering more broadly) individual members of the industry may not see much at all in common with one another, with new subfields being created every day. This makes traditional unionization more difficult as well. After all, how many articles have been written about DevOps and how it breaks walls between System Administrators and Developers? Just tackling this one bridge, entirely within the professional sphere itself, has been a huge challenge. But this helps us.
+
+Ultimately there are two sources to these issues that I can see:
+
+1. Generally, IT industry professionals are not responsible for hiring their own, with some exceptions.
+
+1. The culture of the IT industry, stretching back as far as the 1980's, has always favoured brash individualism over collective solidarity.
+
+Each of these requires a bit to go into, but both fundamentally shape the lack of organization within the IT industry, as well as help identify the things we need to combat to improve this.
+
+## On Hiring in IT - buzzwords, HR, and Startups
+
+* common thing i see people complain about - HR hiring
+* buzzwords abound, filter by keywords
+* testing of employees is hard
+* finding good workers takes time
+* professional certifications are worthless
+
+## On the Toxic Culture of IT
+
+* High focus on individualism, low empathy
+* Rockstars, 10x
+* Nerd in-group (reference Dietrich article)
+* The good - FOSS
+* The good - DevOps, building connections
+
+## Why bother with organization?
+
+* good for people
+* good for tech! (DevOps, etc.)
+
+## The ideal IT union
+
+* descrie the ideal IT union

content/post/problems-in-floss-1.md

@@ -0,0 +1,60 @@
++++
+Categories = ["Philosophy", "FLOSS", "Community"]
+title = "Problems in FLOSS Projects #1 - Feature: Burden or Boon?"
+Description = "Why it's hard to prioritize and balance advanced features with ease of use"
+Tags = ["support", "floss"]
+date = "2020-03-24T00:00:00-04:00"
+menu = "main"
+draft = false
+
++++
+
+## Welcome
+
+Welcome to part one of a series I've decided to create on this blog, called "Problems in FLOSS Projects". I intend this series to be a number of relatively short posts, each one investigating an interesting topic or issue I've seen or faced, mostly within the Jellyfin project, but also in FLOSS self-hosted software in general. Some are technical, some are managerial, some are neither, but all are things that I've thought about and want to write down for the benefit of others who may not have thought of these ideas, or who have and didn't have a name, or even for whom these are constant struggles and who would like validation that they're not alone. I don't intend these posts to have a concrete point or thesis, but just to share a musing or observation, interspersed with my own advice, for others to see. Some of these could have been thought-of-but-unwritten responses to Reddit posts, extensions of chat discussions, or general observations I made, really anthing that didn't "fit" another medium. And some that did and I'm just lifting here for posterity.
+
+As you can tell historically I haven't updated this blog much, but I hope by creating a little series like this without a formal goal, it will encourage me to write more. I hope you enjoy.
+
+## Who uses your software?
+
+Generally speaking, it seems that administrators of self-hosted software tend to fall into to main camps: Users and Admins. Now, yes of course anyone running self-hosted software is generally an "admin", but I mean something specific with these terms, so bear with me. When I use the words "User" and "Admin" capitalized later in this piece, I mean these two definitions.
+
+Users want software that "works", that is to say, fulfills a function. They want self-contained software that can be installed quickly and easily, and that will provide them some functionality. Then, they use the software, often only tweaking or updating it when they feel like it, when they hit a bug, or when a really exciting new feature comes along. Users will generally tolerate small bugs, but big bugs, especially big breaking bugs, tend to turn them right off of a piece of software.
+
+Admins want software that is "interesting", that is to say, provides them joy in and of itself, either to set up, to learn, to discover functionality, or just in general, to tinker. They will definitely use the software as a User does, but for them the joy is in the journey, not the destination, and they'll probably run a nightly or upgrade every release within hours just for the fun of being on the bleeding edge. Admins also tend to tolerate much more and much bigger bugs than Users will, some even reaching true "Hacker" level and helping write the software.
+
+Now, if you've read those two descriptions and thought "Well, sometimes I'm a User, and sometimes I'm an Admin, what a false dichotomy!", you would be right. In fact, for a lot of the things I self-host myself, I certainly fall more into "User" than "Admin". I want it to just sit there and work so I never have to think about it. Of course, with other things, like Jellyfin, I'm an Admin (when my users won't notice). And while you would probably say that almost every first-time self-hoster falls squarely into the User category, for those of us with more experience, professional or otherwise, the line absolutely blurs significantly.
+
+But the real point of these descriptions is less about individuals as a whole, and more about the conceptual space each type represents, like the comparison between Introversion and Extroversion. Every user of your software is going to fall somewhere in these two camps - practical vs. interesting, stable vs. bleeding-edge - though not always in the same place for every piece of software, or even on different days with the same software.
+
+However, we can use these two models to help us figure out a deeper issue: is a feature going to be a Burden, or a Boon?
+
+## Burden or Boon?
+
+Every feature you add to a project/product is going to add more conceptual baggage to the software. A really interesting portrayal of this can be found in UX designer and musician/composer Tantacrul's "Music Software & Bad Interface Design" series [[1]](tttps://www.youtube.com/watch?v=dKx1wnXClcI). In this particular episode, speaking about Sibelius and its Ribbon design, he discusses at length the usefulness of a (good) Ribbon UI in helping solve a major problem that Microsoft originally, and Sibelius later, found with their software: there were just too many features to anyone to find them all. The Ribbon UI was a solution to this; we can debate at length about how successful it was, but it illustrates a real problem with software design.
+
+When you add features, those features have to both serve a purpose, and be accessible to your users.
+
+This seems obvious. After all, why would anyone add a feature if it served no purpose and wasn't accessible to the user?
+
+The problem with self-hosted server software is that *you have to take into account your user concepts when asking this question*. For instance, let's take a very real feature request for Jellyfin: support for SSO.
+
+SSO, or Single-Sign-On, is functionality that allows an end user to authenticate to a single captive portal-like page once, and then be seamlessly logged in to multiple services at once. Think how a random site can log you in with your Facebook account, immediately taking you in a small popup to a Facebook page where you confirm access, and then promptly log you in. This is SSO.
+
+SSO is a really useful feature for a lot of software, especially as a self-hosting admin who runs many services. You can automate authentication and hand it off to another piece of software. You can centralize authentication, as well as ensure that one badly-behaved application cannot leak credentials.
+
+But here's the rub: SSO is an *Admin* feature. The majority, perhaps even the vast majority, of people running self-hosted software don't care about SSO functionality. They don't know the internals of HTTP basic authentication versus application authentication, they don't know what LDAP is, and they certainly don't know what Kubernetes is. These are all extremely advanced features. Most self-hosted admins are, especially at the start, *Users*. This feature is, not only useless to them, but if your only authentication is via SSO plugins, you're going to lose them very quickly.
+
+You must think about whether a feature you add is a Boon to both Users and Admins, or a burden to one group or the other. And it cuts both ways. For instance, a very simple authentication scheme might be all that a User wants. But now the Admin is frustrated, because his more advanced use-case necessitates some extensions to that authentication (for instance, SSO, or more commonly just plain LDAP support), and the software doesn't provide it.
+
+## The sliding scale of User-Friendly
+
+This is a topic I could (and maybe will) write a whole blog post on, but "user friendly" when describing software is almost always a misnomer. User-friendliness is a sliding scale. Something that is friendly for a beginner can easily become tedious for an advanced user, and something that an advanced user sees as conceptually basic can be an unimaginable learning curve for a new user. This is something every software must face.
+
+But the difference with self-hosted software is that you don't use have "users" in the traditional sense, you also have the two conceptual spaces for the administrator as well. If the software has a huge learning curve during initial setup, it will attract Admins but not Users, and if your software is super easy to set up but lacks any advanced features, you will attract plenty of Users but Admins will quickly become frustrated (or, hopefully, help you hack, if you're open to it).
+
+So what is the point of all this? Besides me putting to words these thoughts?
+
+Well, my advice to any aspiring manager/designer/creator of a piece of self-hosted software is this: make sure you think about these things, especially when designing new features. Who does your feature help, Users or Admins? Who is your feature a burden on, Users or Admins, or neither? By asking yourself these questions, and understanding the two types of self-hosted administrators, you can help design software that everyone will like. And when adding features to your project, thinking about which group the feature is targeted at can help you decide how to integrate the feature, whether or not to make it mandatory, and how and where to document it.
+
+I've seen many cases where these concerns aren't thought of, and the result is almost always subpar software. Either Users are unhappy, or Admins are unhappy, and the software suffers for it. Users build community, Admins push the envelope. And worst of all, if both groups are unhappy, no one will use your software at all! Which sometimes, fine, it scratched your itch. But to make something that many people use, that is useful to not just the author, is generally the goal of FLOSS, and taking these issues into account will help you realize that goal. Because we all want FLOSS and self-hosting to take over the world.

content/post/support-vampires.md

@@ -0,0 +1,14 @@
++++
+Categories = ["Philosophy", "FLOSS", "Community"]
+Description = "Everyone's seen one, but might not know what to call them. Here's what to do."
+Tags = ["support vampire", "help vampire", "support", "floss"]
+date = "2020-03-24T00:00:00-04:00"
+menu = "main"
+title = "Support Vampires a.k.a. Help Vampires, and How to Fight Them"
+draft = true
+
++++
+
+## The Psychic Vampire
+
+