FOSS licenses permit, not restrict

Last week, Matthew Wilson shared a very correct take on Twitter:

A few people in the mentions argued that the GPL is doing it wrong by his definition. This is incorrect. Copyleft licenses do not prevent the user from doing things, they ensure that subsequent users can do the same thing.

This may seem like a semantic argument, but there’s substance to it. All licenses (except those that amount to a public domain dedication) contain some conditions, minimal though they may be. It’s important to remember that the default is that you can do nothing with a work. Copyright is by definition a monopoly on a work.The entire point of free and open source software licenses is to tell you what you can do, because the default position is that you can’t.

One of the most annoying things about license wars is the argument that one category of license is somehow more free than another. That’s dumb. Both copyleft and permissive licenses promote freedom, just from different perspectives. Permissive licenses give the next person in line the freedom to do (essentially) whatever they want. Copyleft licenses preserve freedoms for all subsequent users, no matter how many hands the work passes through. There are plenty of philosophical and practical reasons you might choose one class of license over the other (I tend to prefer copyleft licenses, myself), but it’s wrong to paint one or the other as anti-freedom.

Getting back to Matthew’s point, there has been a fair amount of license weaponization in the last few years. By this I mean the use of a license to try to exclude a certain class of user. Some of this I’m sympathetic to (e.g. the “ethical source” movement), some of this I’m not (e.g. the various “you can do what you want, just don’t make a successful software-as-a-service offering” licenses that have popped up). In both cases, I think copyright is the wrong mechanism for achieving the goals.

Excluding classes of users is antithetical to ideals free software and open source. That may be okay. As I’ve written, free software is not the end goal. But if you’re going to claim to be open source, you should act open source.

On CLAs, DCOs, and pinky swears

Recently, Van Lindberg decided to kick over a hornets’ nest on Twitter:

I don’t think either of them particularly change the risk profile to the end user of a project. Both a contributor license agreement (CLA) and developer certificate of origin (DCO) depend on the contributor asserting something that is correct. In my experience, the most common issue is a developer submitting code they can’t. This could be because they’re reusing code under an incompatible (including proprietary) license.

Another possibility is that they are not the copyright owner. This can be the case when contributing as part of a job or while using their employer’s resources. Van suggests that a CLA helps prevent this because it passes through the contributor’s employer’s legal department. That strikes me as naÏve. Most contributors, I suspect, will sign the CLA on their own without consulting anyone else.

Fundamentally, CLAs and DCOs depend on contributors understanding enough about intellectual property to ensure their contributions are valid. Neither mechanism is particularly effective at that.

This doesn’t mean they’re useless. My 2018 Opensource.com article gives more information on that.

Cursed house: The Monkees

This is the first post in a series of personal stories about how my parents’ house has some really bad luck.

I’ve been a fan of The Monkees for nearly as long as I can remember. Davy Jones signed the liner notes for my copy of their greatest hits CD. I not only have watched “Head”, but I own it, and I like it. As a kid, I recall frequently asking my mom if a song on the radio was by The Monkees. Almost every time it turned out to be the Beatles, but that’s neither here nor there.

My lifelong fandom is undoubtedly due to the hours I spent watching the TV show in a hotel room when I was three years old. You see, my family lived in a hotel while we rebuilt our house.

It wasn’t a planned rebuild, mind you. The project was thrust upon us when the house caught fire.

I’m not entirely clear on the details, but somehow the fire happened when the house was in limbo. My parents were stuck with it, but the previous owner got the insurance payment? I don’t know; I was three. At any rate, it turns out that the previous owner had similar circumstances befall them at least one other time. Not suspicious at allllll.

But if the house is cursed, my parents were lucky in one regard: they had the carpets cleaned that night. The dampness slowed the fire long enough for the volunteer fire department to arrive. This kept the house from being a total loss.

It also gave me one hell of a headache. I ran through the house, being a three year old, and immediately fell when my wet shoes hit the vinyl floor in the kitchen. I still remember sitting on the back porch crying. My grandpa was there with us and he let me come spend the night to help me feel better.

I have a vague recollection of my parents showing up at his house later that night or the next morning. I assume they talked about the fire. I don’t remember if I had any reaction to the news or not. Ah, to be young again!

But this post is about The Monkees. So there we are, living in a hotel. My parents, my infant sister, and me. There’s not a lot for a kid to do in a hotel, especially when dad is at work (or working on making the house livable again) and mom is caring for a baby. So I spent what was probably a good deal of time watching TV.

This was around the time that The Monkees were having a resurgence in popularity, and so the show was on TV. I don’t remember specifics, but I know I liked the show. While the jokes went faaarrr over my head, the silliness is evident even to a three year old.

The Monkees got me through what was probably an incredibly stressful winter for my parents. I’ve been a fan ever since.

Balancing incoming tasks in volunteer projects

Open source (and other volunteer-driven) communities are often made up of a “team of equals.” Each member of the group is equally empowered to act on incoming tasks. But balancing the load is not easy. One of two things happens: everyone is busy with other work and assumes someone else will handle it, or a small number of people immediately jump on every task that comes in. Both of these present challenges for the long-term health of the team.

Bystander effect

The first situation is known as the “bystander effect.” Because every member of the team bears an equal responsibility, each member of the team assumes that someone else will take an incoming task. The sociological research is apparently mixed, but I’ve observed this enough to know that it’s at least possible in some teams. You’ve likely heard the saying “if everyone is responsible then no one is.”

The Bystander effect has two outcomes. The first is that the team drops the task. No one acts on it. If the task happens to be an introduction from a new member or the submission of content, this demoralizes the newcomer. If the team drops enough tasks, the new tasks stop coming.

The other possibility is that someone eventually notices that no one else is taking the task, so they take it. In my experience, it’s generally the same person who does this every time. Eventually, they begin to resent the other members of the team. They may burn out and leave.

Oxygen theft

Sometimes one or two team members jump on new tasks before anyone else does. Like the delayed version in the bystander effect scenario, this can lead to burn out. But worse, it can drive away team members who want to take tasks. If they’re constantly missing work because they weren’t able to immediately jump on it, they’ll go find other places to contribute. I call this “oxygen theft” because it’s like sucking all of the oxygen out of the room: it puts out the flames.

I have been an oxygen thief myself. Shortly after I started as the Fedora Program Manager, I became an editor on the Fedora Community Blog. I was publishing regular posts and I happen to be a decent editor, so it made sense to give me that privilege. But because Fedora was my day job, I was often the first to notice new submissions. Over time, I eventually became the only editor working on posts. By accident, the editorial team became a team of one. That’s on my list to fix in the near future.

Solving the problem

Letting either the bystander effect or oxygen theft cases go for too long harms the team. But with volunteers, it’s hard to balance the work. Team members may not have consistent availability. For example, if one of the team members dayjob schedule varies from week. They probably don’t have evenly distributed availability, either. Someone who is paid to be on a project will likely have a lot more time available than someone volunteering.

One way to solve the problem is to take turns being in charge of the incoming tasks for a period of time. This addresses “if everyone is responsible then no one is” by making a single person responsible. But by making it a rotating duty, you can spread the load.

After learning my lesson with the Fedora Community Blog, I was hesitant to be too aggressive with taking tasks as an editor of the Fedora Magazine. But the Magazine team was definitely suffering from the bystander effect.

To fix this, I proposed having an Editor of the Week. Each week, one person volunteers to be responsible for making sure new article pitches got timely responses and the comments were moderated. Any of the editors are free to help with those tasks, but the Editor of the Week is the one accountable for them.

It’s not a perfect system. The Editor of the Week role is taken on a volunteer basis, so some editors serve more frequently than others. Still, it seems to work well for us overall. Pitches get feedback more quickly than in the past, and we’re not putting all of the work on one person’s plate.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Distinguishing between tasks and projects

I was talking to a colleague recently about leading a volunteer group at work. One of the issues she mentioned was that the group sometimes has a hard time separating tasks and projects. If you look around, you’ll find plenty of blog posts (mostly from software companies trying to sell you their tool). Many of them share a similar adherence to the Project Management Institute’s definition of a project. While that can be useful, it’s more formal than necessary.

In my mind, the distinguishing factor is the number of states.Tasks have two states: “not done” and “done”.Projects have multiple states.

For example, I treat doing the dishes as a task. There’s not really an in-between state. Okay, there could be. Scrubbing, rinsing, and drying could all be distinct states. In practice, a dish moves between the three so quickly that it’s of no benefit to track the state. Doing the dishes is a single act in terms of my time. I’m not going to start and then pause midway through (barring my kids doing something that requires immediate attention).

Laundry, on the other hand, I treat as a project. It has distinct states of sorting, washing, drying, and folding. Unlike the dishes example, they don’t happen all at once. I’ll load the washer and then I have to wait until I can put the clothes in the dryer.

To use work examples, writing an email is a task. Yes, there’s a state of “writing” and I may not compose it all at once, but it’s essentially a single thing. Writing a release announcement is a project. First I write it, then it gets reviewed, then it gets scheduled.

This brings up another point about the states. Tasks change state in one direction, but projects can move between states. Once they’re done, they’re done. After I send an email, it’s done. New tasks may come as a follow-up, but those are new tasks. The release announcement may go back and forth between “writing” and “review” several times before it’s done.

The astute reader will notice that the states sound a lot like tasks. You can look at the laundry project as a collection of four tasks: sort the laundry, load the washing machine, load the dryer, fold the laundry. That’s a valid approach. For me, it makes more sense to think about it in states instead of a collection of steps.

Part of this is probably due to the tools I use. For tasks, I use a todo list application (Todoist, specifically) to track and plan. For projects, I use a Kanban board (Trello, generally, but Taiga for a few things. And Todoist’s new board feature for my laundry. More on all of this in a future post). For particularly complex projects, I’ll add sub-projects or tasks to track them more granularly.

Sidebar: why PMI’s definition is too formal

The Project Management Institute defines a project as “It’s a temporary endeavor undertaken to create a unique product, service or result.” While this is not unreasonable in the context of my conversation, the page goes on to add a lot of extra baggage. In common usage, a project is something that takes multiple steps to accomplish. The structure, process, and documentation of a Project™ are entirely unnecessary for how most people use the word.

File a bug, but where?

It’s easy to tell someone to file a bug. Knowing where to file it isn’t quite as simple. In a large project like Fedora, there is no One Tracker to Rule Them All.

Red Hat Bugzilla comes the closest. That’s where most software bugs should be filed. Except for Fedora CoreOS which would rather you use their GitHub tracker. And a few other components, which would very much prefer issues be filed upstream.

But for non-software issues, Bugzilla may or may not be the place. Components still exist for documentation and websites, although those are mostly handled via Pagure repos now. (I should really remove those components.) And some teams discuss software features in their Pagure repo for collaboration and then might open a Bugzilla bug if other tools need one.

Of course, knowing which platform is only the start. You also have to know which component (in Bugzilla) or repo (in Pagure) is right. This isn’t always clear when you’re familiar with the inner workings of the project and is entirely opaque to outsiders. A casual user is not going to know (or care) which URLs happen to be owned by the websites team versus the docs team versus who knows what other team.

And that, dear reader, is one of the key features of a centralized tracker like Bugzilla: mis-filed bugs can be trivially passed to the right team. With independent repos, you force users to know your project’s org chart

Of course, Bugzilla can be pretty heavy and is generally more complicated than you need. There’s no right answer. There’s just how you’re willing to balance the tradeoffs.

In general, I think putting software issues (bugs, features, etc) in Bugzilla and process issues in a team’s Pagure repo is the right approach. But ultimately, teams decide for themselves how they will work.

[If you are intrigued by this half-baked post, you’ll enjoy my book on program management for open source projects, coming from The Pragmatic Bookshelf in 2022.]

Book review: A Place to Start

Jim Grey is a pretty ordinary guy. So why bother reading stories of his life? Because he tells them so well.

I first came to know of Jim through his roads website. At some point, I started reading his blog “Down the Road“. I can’t recall how long it’s been now, but it’s probably the better part of a decade, if not from the beginning in 2007. Although we’ve never met, I’ve come to feel like I know him. Not just because we share similar interests and have mutual friends, but because the way he is able to write his personal stories in a way that welcome strangers in.

Jim does not share every detail; his writing respects the privacy of those in his life. Nonetheless, he is able to warmly and openly share his stories in a way that invites to sit down and listen. There is no false modesty, no exaggeration, and no self-importance. Just honest tales of his life shared because he wants to share them.

Down the Road started in 2007 as a way to process and recover from a rough time in his life. Jim’s new (okay, six months old at this point) book A Place to Start collects some of the posts from the first two years of the blog.

The book is split into three parts: stories, essays, and faith. The stories are personal tales from all eras of Jim’s life. Told in no discernible order, they’re more like a conversation than a timeline. The short essays section contains reflections on lessons Jim has learned over the years. The faith section contains a mix of his personal experiences with his Christian faith along with what I would call sermons.

Admittedly, the faith section was the least engaging part for me. Being religiously indifferent myself, I suppose I’m not inclined toward that kind of story. Nonetheless, I do enjoy the way he is able to discuss his faith in a way that does not feel like evangelism. He shares his beliefs and how they color his life; the reader is free to do with that what they will.

Since each chapter is a blog post, they’re all short. This makes A Place to Start a great book for when you can only read in quick bursts. Even if you’ve never heard of Jim Grey before, this book with worth a read.

A Place to Start is available in print and digital forms from Midnight Star Press. I received no compensation for this review.

Other writing: March 2021

What have I been writing when I haven’t been writing here?

Now you see me!

Stuff I wrote

Fedora

Stuff I curated

Fedora

Projects shouldn’t write their own tools

Over the weekend, the PHP project learned that its git server had been compromised. Attackers inserted malicious code into the repo. This is very bad. As a result, the project moved development to GitHub.

It’s easy to say that open source projects should run their own infrastructure. It’s harder to do that successfully. The challenges compound when you add in writing the infrastructure applications.

I understand the appeal. It’s zero-price (to write; you still need the hardware to run it). Bespoke software meets your needs exactly. And it can be a fun diversion from the main thing you’re working on: who doesn’t like going to chase a shiny for a little bit?

Of course, there’s always the matter of “the thing you wanted didn’t exist when you started the project.” PHP’s first release predates the launch of GitHub by 13 years. It’s 10 years older than git, even.

Of course, this means that at some point PHP moved from some other version control system to Git. That also means they could have moved from their homegrown platform to GitHub. I understand why they’d want to avoid the pain of making that switch, but sometimes it’s worthwhile.

Writing secure and reliable infrastructure is hard. For most projects, the effort and risk of writing their own tooling isn’t worth the benefit. If the core mission of your project isn’t the production of infrastructure applications, don’t write it.

Sidebar: Self-hosting

The question of whether or not to write your infrastructure applications is different from the question of whether or not to self-host. While the former has a pretty easy answer of “no”, the latter is mixed. Self-hosting still costs time and resources, but it allows for customization and integration that might be difficult with software-as-a-service. It also avoids being at the whims of a third party who may or may not share your project’s values. But in general, projects should do the minimum that they can reasonably justify. Sometimes that means running your own instances of an infrastructure application. Very rarely does it mean writing a bespoke infrastructure application.

Indiana COVID-19 update: 27 March 2021

I haven’t written an update in nearly two full months. This is only slightly due to laziness. Mostly, it’s because the state’s numbers have been unremarkable. I mean that in a good way. We’ve consistently trended downward in infections (and positivity), hospitalizations, and deaths. However, we seem to have reached the floor and I’m concerned that the early indications suggest an increase. As usual, I am updating my dashboard most days.

Changes in trends

Five days in the past week (including the three most recent) had a daily increase in the hospitalization count. Two days had a 7% or greater daily increase. These are some of the largest increases on record. The hospitalization count is 12% higher than a week ago. Meanwhile, we’ve had a full week of week-over-week increases in positive cases. Only one day in the last 10 showed a week-over-week decline.

Daily and week-over-week changes in COVID-19 hospitalizations in Indiana.

Deaths continue to slowly trend downward, but if the increase in hospitalization holds, expect an uptick in deaths soon. After under-predicting the deaths during the surge in the fall, the Institute for Health Metrics and Evaluation (IHME) models are consistently over-predicting deaths. However, it does not appear that the most recent model run takes the end of the mask mandate (see “Changes in policy”), so it will be interesting to see how they fare in a month.

Observed and forecasted COVID-19 deaths in Indiana.

Changes in behavior

The IHME’s latest policy brief says mobility in Indiana is 8% below the pre-pandemic baseline. This is a big jump from the 20–25% of just a month or so ago. Meanwhile, mask usage has fallen slightly to 72%. Given these, it’s not hard to see why the numbers are picking back up again. These are both trends specifically called out as factoring into the “worst-case scenario.” (Note that the “reference scenario”—or most likely scenario—is what I plot on my dashboard.)

Changes in policy

Governor Holcomb announced earlier this week that the mask mandate will be gone on April 6. This is bad policy. While all Hoosiers 16+ will be eligible for vaccination beginning on March 31, the earliest a newly-eligible person will be fully vaccinated is April 14. And that assumes that the person can get the vaccine that day and that they receive the one-dose Johnson & Johnson vaccine. Recall that the CDC says people reach full vaccination two weeks after receiving the last shot.

In other words, in the impossibly-best case scenario, the mask mandate ends a week before the state’s (adult) population is fully vaccinated. The more likely case is that we don’t hit the 70% threshold for weeks, perhaps months. Holcomb says “Hoosiers know the science” and will continue to wear masks and follow distancing guidelines once the mandate becomes an advisory. I wonder what Hoosiers the governor has been talking to. Considering how many crowded restaurant parking lots and improperly-worn masks I’ve seen in the past week, I don’t believe him.

This is infuriating, because a mask mandate is essentially free. This is particularly true given how little effort the state put in to enforcing it. Ending the mandate early sends the wrong message. We can only hope that vaccinations outpace the virus. We deserve better than this.