Other writing: February 2022

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

Stuff I wrote

Program Management for Open Source Projects

Duck Alignment Academy


Other writing: January 2022

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

Stuff I wrote

The Pragmatic Programmers

Duck Alignment Academy


Stuff I curated


On Jono Bacon’s discussion of Reddit karma

Last week, Jono Bacon published a YouTube video discussing the karma system used by Reddit. It’s worth 28 minutes of your time if you’re thinking about a reputation system for your community. I don’t have any disagreements, but there are a few “yes, and”s that popped up as I watched it.

What’s karma for?

A fundamental problem with karma is that it applies to posts/comments, not to accounts. Yes, Reddit displays a net karma score on account profiles, but it doesn’t do anything with it. A large number of upvotes will move a post or comment toward the top. A large number of downvotes will hide a comment behind a “wow, do you really want to see this crap?” (my words) link. But apart from removing a posting frequency speedbump for new accounts, the account’s karma doesn’t actually mean much.

Karma is non-specific

Another big issue with Reddit karma is that it’s the same across the entire site. Jono talked about using karma as a metric of credibility. If you narrowly define “credibility” as “knows what the community likes”, then that works. But I might earn a bazillion points for my insightful open source posts. When I go to post in an small engine repair subreddit, my karma comes along with me.

Just because I can successfully participate in one subreddit, that doesn’t mean I can in another. And it’s certainly not a measure of expertise on a topic. Jono alludes to this by talking about how karma doesn’t distinguish between funny and helpful, for example.


You can’t buy karma. That’s one of the benefits of Reddit karma. But you can buy accounts to apply karma. Whether you pay money to a bot farm or just wield your influence on another platform, you can drive upvotes or downvotes to an account of your choosing. Since karma is mostly meaningless at the account level, the direct harm of this is fairly small. But brigading is always a concern in online communities.

Okay, so then what?

Reddit karma has its downsides. But it is very simple, which is a huge benefit. I tend to favor the more account-centric systems like Discourse trust levels and StackExchange reputation. Sites like ArsTechnica have an up/down vote systems with an optional tag to explain why you’re giving the vote. If Reddit’s karma was per-subreddit, it would be more useful as a measure of credibility.

Hunga Tonga-Hunga Ha’apai eruption pressure wave in Indiana

Over the weekend, the volcanic island of Hunga Tonga-Hunga Ha’apai erupted in the south Pacific. People as far away as Alaska heard the sound. Here in Indiana, we did not. But we were able to detect the shock wave from the explosion as a rapid pressure change.

Graph of barometric pressure at my house showing an abrupt rise and fall in pressure as the shock wave passed on Saturday morning.

In fact, you can watch it cross the continental US by plotting the pressure changes, as Daryl Herzmann did.

A little after midnight, the pressure wave came around from the other side of the globe. Alerted to this possibility by Daniel Dawson, I grabbed the graph from my weather station again.

Graph of barometric pressure at my house showing an slight rise and dramatic fall in pressure as the shock wave passed again on Sunday morning.

I don’t have much to add. It’s just a neat example of how our planet works. Some of the satellite imagery is absolutely mesmerizing. Unfortunately, it sounds like the damage to nearby islands may be catastrophic. The BBC reported that some islands may have been completely covered by seawater. Tonga is already gravely threatened by rising sea levels, and disasters like this can only make the situation worse.

Edited 17 January 2022 at 3pm EST to say the pressure wave came from the other direction, not around again. Thanks to Shelley Melchior for the correction.

Indiana COVID-19 update: 15 January 2022

Welcome to the new year, where we’re still dealing with COVID-19. The stats are a little muddy, both because of the holidays throwing a wrench into the reporting and also because I’m seeing some things I don’t quite expect. More on that below.

The recent past

In my last update just before Christmas, I noted that we had reached a peak in cases and hospitalizations. Possibly deaths as well, although that remained unclear. The cases and hospitalizations continued to slowly decline over the next few days, until beginning to rise again Christmas weekend.

Current state

Last month, I wrote “With vaccines available, we should see hospitalization and death rates far below [winter 2020–1]. On the other hand, indoor masking is nearly non-existent and the Omicron variant presents a rather significant unknown.” Omicron is no longer an unknown.


As Micah Pollak predicted, Indiana is seeing record levels of new cases. His “optimistic” (my word) scenario had 7,800 new cases today. His “pessimistic” scenario had us at 8,200 ten days ago. The pessimistic scenario was close: the 7-day moving average of new cases crossed 8,200 on January 3. As of yesterday’s update, the average is 13,935—79% higher than the optimistic scenario.

There’s some indication that we’re approaching the peak for new infections. Week-over-week and week-over-two-week changes in new cases are trending downward, as is the difference in weekly cumulative cases. While still higher than almost any other time during the pandemic, the slowing is a good sign. However, there are a few caveats:

  • Test availability, particularly for rapid tests, is pretty limited anecdotally
  • At-home tests are not included in the state’s data
  • Omicron has a higher percentage of asymptomatic infections (source, p1), which could plausibly mean a smaller percentage of infections are being detected.
Week-over-week (blue) and week-over-two-week (red) changes in COVID-19 cases

So we’re maybe peaking, maybe not. Some states have already peaked, which lends some credence to the “actually peaking” scenario. From what I’ve seen, case rates drop dramatically after the peak. Presumably because there’s just no one left to infect? 42.5% (and climbing!) of people reporting test data to the state are testing positive right now. At this point, there’s basically nothing we can do about it.

Our models suggest that transmission is so intense, and the wave is cresting so fast, that policy interventions such as mask mandates, increased third-dose vaccination coverage, and increased vaccination of the hesitant will have no real impact on this wave. … Given that transmission cannot be controlled, the toolkit used during previous waves of the pandemic will not work. In our models, testing strategies will not curtail the rapid Omicron wave, nor will increased mask use.

Insitute For Health Metrics and Evaluation, January 13, 2022 US policy report


COVID-19 is overwhelming hospitals. The nine-country district that includes Lafayette has 0–3 available ICU beds most days. Statewide, we have set several new hospitalization counts in the last week. This is a little misleading: the Institute for Health Metrics and Evaluation (IHME) estimates roughly half of COVID-19 nationwide are hospitalized with COVID, not for COVID. Nonetheless, they’re still occupying beds, which are increasingly harder to come by. COVID ventilator usage remains at a higher percentage of total capacity than in last winter’s surge.

Daily (blue) and weekly (red) changes in COVID-19 hospitalizations.

What encourages me is that the increase in hospitalizations is rising more slowly than the increase in cases. This was not the case in previous waves. It suggests we’re seeing what others have reported: Omicron is individually less severe. From a public health perspective, of course, it’s still a huge problem. Don’t get in a car accident or have a heart attack for a while.


This is where I get confused. Weekly cumulative deaths continue to decrease. Weekly cumulative deaths (the total of deaths in the last 7 days minus the total of deaths in the 7 days before that) have been decreasing since about December 20. Given that hospitalizations began to rise around Christmas, I’d expect to see an increase in the deaths by now. We’re not seeing that yet. I’m glad if that pattern holds, but it confuses me. With hospitalizations still on the rise, we’ll have to wait and see.

Daily COVID-19 deaths

I want to take a moment to note that over 30% of Indiana’s COVID-19 deaths have occurred since July 1, 2021. This represents almost 6,000 Hoosiers who didn’t have to die. The vaccines are lifesavers and anyone who claims otherwise is morally responsible for these deaths.

Looking ahead

IHME’s latest model run shows that we peaked in estimated infections earlier this week. Reported infections will peak in about 10 days. By mid-March, infections will be back down to about 1,200 per day. That’s a rate we haven’t seen since the beginning of the Delta wave in early August. Hospitalizations will peak at the beginning of February. The model predicts both all-bed and ICU usage will be nearly twice the December 2020 peak.

The near-term historical death data on IHME’s page does not match reality, so I won’t incorporate it into my dashboard or give it any credence here. I suspect it may be that the historical data is based on day-of-report, not day-of-death. However, that theory has a lot of holes.

Instead, I’ll talk about the previous run, which matched reality much better. And it turns out it’s the first model run I’ve added to my dashboard since the end of September. Oops.

Currently, the January 8 model is under counting daily deaths by about eight per day. The model shows a minimum on the 8th, with a rise to 60 by the end of the month. This is about half of last winter’s peak day, or about the same as we were in the week before Christmas 2021.

Observed and projected COVID-19 deaths.

This model run forecasts a return to single digit daily deaths the second week of March. The last time we were in single digits was August 7, 2021.

Maybe we should think about how we use language ecosystems

Over the weekend, Bleeping Computer reported on thousands of packages breaking because the developer of a package inserted infinite loops. He did this with intent. The developer had grown frustrated with his volunteer labor being used by large corporations with no compensation. This brings up at least three issues that I see.

FOSS sustainability

How many times have we had to relearn this lesson? A key package somewhere in the dependency chain relies entirely on volunteer or vastly-underfunded labor. The XKCD “Dependency” comic is only a year and a half old, but it represents a truth that we’ve known since at least the 2014 Heartbleed vulnerability. More recently, a series of log4j vulnerabilities made the holidays very unpleasant for folks tasked with remediation.

The log4j developers were volunteers, maintaining code that they didn’t particularly like but felt obligated to support. And they worked their butts off while receiving all manner of insults. That seemingly the entire world depended on their code was only known once it was a problem.

Many people are paid well to maintain software on behalf of their employer. But certainly not everyone. And companies are generally not investing the sustainability of the projects they rely on.

We depend on good behavior

The reason companies don’t invest in FOSS in proportion to the value they get from it is simple. They don’t have to. Open source licenses don’t (and can’t) require payment. And I don’t think they should. But companies have to see open source software as something to invest in for the long-term success of their own business. When they don’t, it harms the whole ecosystem.

I’ve seen a lot of “well you chose a license that let them do that, so it’s your fault.” Yes and no. Just because people can build wildly profitable companies while underinvesting in the software they use doesn’t mean they should. I’m certainly sympathetic to the developers position here. Even the small, mostly unknown software that I’ve developed sometimes invokes a “ugh, why am I doing this for free?” from me—and no one is making money off it!

But we also depend on maintainers behaving. When they get frustrated, we expect they won’t take their ball and go home as in the left-pad case or insert malicious code as in this case. While the anger is understandable, a lot of other people got hurt in the process.

Blindly pulling from package repos is a bad idea

Speaking of lessons we’ve learned over and over again, it turns out that blindly pulling the latest version of a package from a repo is not a great idea. You never know what’s going to break, even if it’s accidental. This still seems to be a common mode in some language ecosystems and it baffles me. With the increasing interest in software supply chains, I wonder if we’ll start seeing that as an area where large companies suddenly decide to start paying attention.

My 2021 Todoist year in review

I use Todoist to manage my to-do lists. I was surprised to receive a “2021 year in review” email from the service the other day, so I thought I’d share some thoughts on it. I’m not what I’d call a productivity whiz, or even a particularly productive person. But the data provide some interesting insights.

2021 status

First, I apparently completed 2900 tasks in 2021. That’s an interestingly-round number. The completed the most tasks in November, which was a little surprising. I don’t feel like November was a particularly busy month for me. However, I’m not surprised that May had my lowest number. I was pretty burnt out, had just handed off a major project at work, and took over e-learning for my kids. May was unpleasant.


Looking at the days of the week, Thursday had the most completed tasks. Saturday had the fewest (yay! I’m doing an okayish job of weekending.)

Zooming in to the time of day, the 10 AM–12 PM window was my most productive. That makes sense, since it’s after I’ve had a chance to sort through email and have my early meetings. I definitely tend to feel most productive during that time. Perhaps I should start blocking that out for focus work. Similarly, I was most likely to postpone tasks at 3pm. This is generally the time that I either recognize that I’m not going to get something done that day or that I decide I just don’t want to do that thing.

Making sense of it all

Todoist says I’m in the top 2% of users in 2021. Perhaps that argues against my “I’m not particularly productive” assertion. It’s more likely that I just outsource my task management more than the average person. I put a lot of trivial tasks in so that I can get that sweet dopamine hit, but also that I just don’t have to think about them.

I don’t remember if Todoist did a year in review last year, but if they did I spent no time thinking about it. But based on what I’ve learned about the past year, I’m going to guard my late-morning time a little more jealously. I’ll try to save the trivial tasks for the last hour of the work day. This may prove challenging for me. It’s basically a more boring version of the marshmallow test.

Other writing: December 2021

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

Stuff I wrote


Stuff I curated



Indiana COVID-19 update: 21 December 2021

Oh hey, one of these again. I’m mostly doing this as a timestamp of sorts. Indiana identified its first case of the Omicron variant about a week and a half ago. Given the 2–3 day doubling interval seen elsewhere, Indiana could potentially see daily case records by mid-January. Even if Omicron proves to be less virulent, the increased transmissibility may result in steady or increased hospitalizations and deaths. So that’s what the future might hold. Where does the present stand?

Current state

Cases have peaked after climbing since around Halloween. My “weekly cumulative cases change” (the change in the sum of the daily positive cases for the last seven days compared to the sum for the seven days prior) has been in the single negative digits for the last nine days. It was as high as 95% earlier this month. The rate of decrease is slowing a bit in the last few days, though.

Week-over-week (blue) and week-over-two-week (red) differences in COVID-19 cases

Hospitalizations have peaked as well. We spent five consecutive days above 3,000. While we’re below that number again, we’re still at a higher hospitalization rate than the peak of the Delta variant wave in late summer. Late last week, we high a pandemic low for percentage of available ICU bed capacity statewide. As I told my friend the other day, I’m not personally concerned about COVID, I’m concerned about driving.

Day-over-day (blue) and week-over-week (red) changes in hospitalizations.

It’s hard to tell if deaths are peaking or not. The numbers tend to get revised upward for longer and longer periods these days. I do know that (as of this writing), 53 people died a week ago. That’s the highest single-day death toll since early February. While the current cumulative weekly death difference shows a decline starting yesterday, I think the 15–20% numbers a few days back are probably closer to reality. Considering that hospitalization just peaked on Thursday, we’re probably a few days out from the peak in deaths.

Coming up

The Institute for Health Measurement and Evaluation hasn’t done an Indiana model run since 17 November. They’re currently trying to incorporate Omicron into the model. Looking at last winter, we’re at or slightly ahead of this time a year ago. Depending on what measure you look at, the peak last year was in roughly mid-December. With vaccines available, we should see hospitalization and death rates far below that miserable winter. On the other hand, indoor masking is nearly non-existent and the Omicron variant presents a rather significant unknown.

Indiana is the worst state for COVID safety, with low vaccination and high hospitalization. This is a failure of leadership, especially considering that most deaths since July 1 would have been prevented with better vaccination rates. Nearly 25% of Indiana’s total COVID-19 fatalities could have been avoided had right-wing politicians and media not made COVID-19 into a culture war.

As usual, I’ll keep my dashboard updated most days that the Department of Health provides data.

The right of disattribution

While discussing the ttyp0 font license, Richard Fontana and I had a disagreement about its suitability for Fedora. My reasoning for putting it on the “good” list was taking shape as I wrote. Now that I’ve had some time to give it more thought, I want to share a more coherent (I hope) argument. The short version: authors have a fundamental right to require disattribution.

What is disattribution?

Disattribution is a word I invented because the dictionary has no antonym for attribution. Attribution, in the context of open works, means saying who authored the work you’re building on. For example, this post is under the Creative Commons Attribution-ShareAlike 4.0 license. That means you can use and remix it, provided you credit me (Attribution) and also let others use and remix your remix (ShareAlike). On the other hand, disattribution would say something like “you can use and remix this work, but don’t put my name on it.”

Why disattribution?

There are two related reasons an author might want to require disattribution. The first is that either the original work or potential derivatives are embarrassing. Here’s an example: in 8th grade, my friend wrote a few lines of a song about the destruction of Pompeii. He told me that I could write the rest of it on the condition that I don’t tell anyone that he had anything to do with it.

The other reason is more like brand protection. Or perhaps avoiding market confusion. This isn’t necessarily due to embarrassment. Open source maintainers are often overworked. Getting bugs and support requests from a derivative project because the user is confused is a situation worth avoiding.

Licenses that require attribution are uncontroversial. If we can embrace the right of authors to require attribution, we can embrace the right of authors to require disattribution.

Why not disattribution?

Richard’s concerns seemed less philosophical and more practical. Open source licenses are generally concerned with copyright law. Disattribution, particularly in the second reasoning, is closer to trademark law. But licenses are the tool we have available; don’t be surprised when we ask them to do more than they should.

Perhaps the bigger concern is the constraint it places on derivative works. The ttyp0 license requires not using “UW” as the foundry name. Richard’s concern was that two-letter names are too short. I don’t agree. There are plenty of ways to name a project that avoid one specific word. Even in this specific case, a name like “nuwave”—which contains “uw”—because it’s an unrelated “word.”

Excluding a specific word is fine. A requirement that excludes many words or provides some other unreasonable constraint would be the only reason I’d reject such a license.