Management: “we’re going into maintenance mode”

Devs: “You mean we get to work on whatever we want?!”

Per the thread, it’s possible this problem could’ve been solved by burying the site in affiliate links…

Edit: also, bluntly, sometimes objections have answers that can’t be said. “DevOps won't want to support another service.”…”that’s because our devops engineers all think you’re an overpaid jackass and are strongly inclined to reject your ideas out of the gate. My one other idea they liked, so they’ll probably take a chance on another one.” What’s hard but important to remember is that sometimes you’re the person that things can’t be said to.

It's amazing how much we continue to learn about these conditions.

Total amateur here, but it strikes me that one important difference is that performance matters in software in a way that it doesn’t in mathematics—that is, all proofs are equally valid modulo elegance. That means that abstractions in software are leaky in a way that abstractions in mathematics aren’t.

In other words, in software, the same systems get reused in large part because they’ve been heavily refined, in terms of performance, unexpected corner-case behavior and performance pitfalls, documentation of the above, and general familiarity to and acceptance by the community. In math, if you lay new foundations, build some new abstraction, and prove that it’s at least as powerful to the old one, I’d think that you’d be “done” with replacing it. (Maybe downstream proofs would need some new import statements?)

Is this not the case? Where are people getting stuck that they shouldn’t be?

There are things you can do to try and even things out. Etherium has been considering “quadratic voting” to solve a similar problem (in this case, that would look like tracking consumption and increasing the unit price of fuel as you consume more fuel, so that cost goes up quadratically with consumption). That seems hard to enforce, though, and doesn’t help with foreign opportunists.

Yes! I would add that IMO the communication style can be learned and there are great rewards for doing so.

I believe the rough statistic that 20% of people on a typical project are contributors. I don’t believe that it’s because the other 80% are losers. IME it’s because no serious effort has been made to include them, make sure they understand wtf is going on around them, and help them solve whatever is holding them back.

If you do this, a) it does work, and b) the need for small teams becomes apparent because the now-onboarded person can’t find anything that isn’t already being worked on, so they (with encouragement) start a new thing. And there are limits to people’s ability to understand what’s happening, especially if they’re inexperienced, and some people really don’t have the skills to contribute, but by and large, building bridges for people is still highly worth doing.

Before AI, I worked at a B2B open source startup, and our users were perpetually annoyed by how often we asked them to upgrade and were never on the latest version.

Parenting children is impossible, therefore all parenting lies on a spectrum from terrible to catastrophic, and it’s hard to know how you did until they grow up (if ever) because there’s a lot of sensitivity and subtle emotional stuff, especially at very young ages, which are the most important and the ones you remember the least. I’m certain there are screen-free parents who are worse for their kids than a good chunk of tablet-hander-outers

I sometimes wonder if modularity will become even more important (as it has in physical construction, e.g. with the move from artisanal, temperamental plaster to cheap, efficient drywall), so that systems that AI is not able to reliably modify can easily be replaced.

I really like to understand the practice of software engineering by analogy to research mathematics (like, no one ever asks mathematicians to estimate how long it will take to prove something…).

Something I think software engineers can take from math right now: years of everyone’s math education is spent doing things that computers have always been able to do trivially—arithmetic, solving simple equations, writing proofs that would just be `simp` in Lean—and no one wrings their hands over it. It’s an accepted part of the learning process.

It made me cautiously optimistic that all of Anthropic’s work on alignment, which they did for AI safety, is actually the cause of Claude code’s comparatively superior utility (and their present success). I wonder if future progress (maybe actual AGI?) lies in the direction of better and better alignment, so I think this is super cool and I’m suddenly really interested in experiments like this

Not like human programmers. I would never do this and have never struggled with it in the past, no...

When you publish a library, people are going to use it more liberally and in a wider range of contexts (which are therefore harder to predict, including whether a given violation requires human intervention)

Given all that, where are professors supposed to find and hire students who don't want to stay in academia themselves? I think a lot of these students wind up being aspiring immigrants, and I'm not surprised that a lot of them would also have a hard time finding a place for themselves after graduating and that many of them would leave. Also, the abstract seems to argue that that US still benefits greatly from this arrangement: "though the US share of global patent citations to graduates' science drops from 70% to 50% after migrating, it remains five times larger than the destination country share."

They had a great discussion with Kelsey Hightower about it[^1], and his answer (which I liked a lot) was basically just that maintainers’ only real obligation was to be transparent about governance. If you want to be a dictator and ignore bugs and contributions that aren’t personally compelling to you, that’s fine—but please just put that in the repo. That way, people who are trying to build a business on open source work and want customers, or to build trust with users for any other reason, can distinguish themselves from maintainers that don’t care (as is their right). Otherwise the reputation of Open Source as a whole suffers.

[^1]: The whole episode is good but here’s the part where Kelsey argues that people just need to be transparent: https://youtu.be/13ctYOu8TsA?si=cI8TwHX6tAaCwH6o&t=1320