I finished this feature PR for ss14 kindof recently. I took these timers that I made in August and finished the job. This post isn’t about the feature, but something I wasn’t able to properly articulate until I talked to some other devs:

Organizational Scaling

The ss14 project has existed for like 4 years in my mind, which means it’s considerably older. curl -s https://api.github.com/repos/space-wizards/space-station-14 | grep 'created_at' gives 2017-05-22T01:57:51Z, so almost 7 years before the repo warranted its own github account¹. My august PR was 19471; my january PR was 24189; there have been 4718 github items in the previous 5 months, and 19000 in the previous ~6 years; simplified: +20% dev activity over 6 months.

Why? The reasons aren’t important. The players, and therefore devs, are switching to 14 from 13. It’s not at feature parity with the original game yet, but the positives from a 15-year-hindsight refactor are outweighing the negatives. An explosion doesn’t crash the server. It’s on Steam, not Byond. The ss14 discord rotates through pride icons; ss13 servers are 4chan communities.

Our case study, Casey, does most of the code review. Last month, Casey reviewed 178 ss14 PRs, and opened 138. He’s not in charge of the project officially², but he is doing the most work, and he is the most responsive PM to help requests, so the devs see him that way. He’s the defacto head/principal developer, if you’re inclined to form such hierarchies. So why is he opening nearly 5 PRs per day himself? Short answer: probably, he enjoys it.

Long Answer:

There aren’t a dozen maintainers closing the issue/PR backlog³; just some PMs who’ve deemed closing it a waste of limited resources⁴. They’re aware of the growth problem. They’ve just minted junior (as in under 18) maintainers, and added a #pr-review-request channel, for contributors to request peer review, in theory offloading some mounting review work. PMs would tell you there aren’t enough qualified contributors to deputize as maintainers. Why?⁵

I’ve posted about my demoralizing ss14 new developer experience. Since that time I’ve sporadically browsed the help channel, submitted PRs that weren’t bulldozed, and met some nice people!

I have some Thoughts.

SS14’s development necessitates? a lack of trust between project manager and potential-maintainer beyond the average open source project:

• Open source games attract a lot of first-time devs
• ECS architecture, client-server architecture, and an event bus – all new to most intermediate non-game devs
• In-house game engine necessitates further project-specific knowledge
• SS14 itself is dwarf-fortress levels of complicated⁶
• Being an obscure videogame with a high learning curve, users are unusually “passionate”⁷ about balance and feature updates
• Inadequate⁸ public relations between unpaid developers and entitled community causes friction

As a result, SS14’s codebase becomes unapproachable:

• The above barriers to entry coupled with open source accessibility mean lots of dev churn
• Old devs recognize the futility of spoonfeeding the average new dev, sequestering knowledge

Devs tend to want to implement features over e.g. documentation, code review, and helping new devs. SS14 just skews more in that direction due to some unique properties. The community is also half(?) Russian, but they have almost no project representation⁹.

So, new maintainers aren’t cultivated, and the “leads” contentedly open 5 PRs a day. </Long answer>.

Last week I asked Casey for a new thing to work on “that wasn’t waiting on anything else”. I felt like he wasn’t used to being asked the question. He said “not sure”, I clarified, he gave me a few things, and then DMed me an hour later, and then 2 days¹⁰ later, with ideas.

Takeaways

What happens if/when Casey burns out? As above, so below. Putting Casey in this position raises our bus factor, and churns our senior devs like our intimidated juniors. One of many scale-mitigating factors:

Some subset of devs will respond to poor documentation by writing good documentation. Some leads will respond to review backlog by delegating maintainers. This is ultimately a self-correcting problem, there’s just growing pains in organizational scaling, a lag that burns everyone.

• The barrier to editing docs needs to be tiny. It’s open source. Maintainers should step in after a contributor identifies a docs problem, instead of having to review all docs changes.
• New devs need guidelines for getting information. Which docs to start with, where to ask when docs come up short, and when is DMing justified? Clearly delineate spoonfeeding so maintainers don’t burn out overextending.
• Dev hats need to be granular, self-assignable, toggleable. “I don’t answer questions in DMs”, “Ask me engine questions”, “Don’t ask me to review PRs” etc. components on top of “Project Manager” or “Junior Developer” roles.

I don’t think this would help a corporate project as much, because there is a commons-tragedy in appearing productive during layoff season. But it’s on my mind now.