--- title: "Maintaining a repository I did not plan to maintain" date: "2021-11-01T05:00:00.000Z" categories: "Open source" canonical: "https://xraph.com/writing/six-years-of-issues" --- # Abstract Flutter Unity Widget crossed two thousand stars and several thousand issues. What the arithmetic actually looked like, and the three habits that kept it survivable. ## The arithmetic Stars and issues measure different things and grow at different rates. Stars measure how many people found it. Issues measure how many people are, in some sense, now your responsibility. My rough categorisation of the issue tracker over its first years: - Around sixty per cent were build configuration on somebody else's machine. Gradle versions, Unity export settings, a manifest merge conflict, a Podfile with an incompatible deployment target, a Unity minor release that changed its export layout. - Around twenty per cent were real defects, concentrated heavily in lifecycle. - Around fifteen per cent were requests for platforms or engine versions I had no way to test. - The remainder were people helping each other, which was the best part of it. Every Unity release, every Flutter release and every Gradle release could generate a week of work, and none of them were coordinated with each other or with me. ## Three habits that helped **A reproduction template.** Requiring a minimal reproduction with exact versions closed roughly half the incoming issues before I read them. Not because people gave up, but because assembling the reproduction is how most people find their own misconfiguration. It felt unfriendly to add and it did more for sustainability than any code change I made. **Declining what I could not test.** Merging support for a platform I have no device for hands users a feature that will break silently and a maintainer who cannot debug it. Every time I broke this rule I regretted it within two months. **Answering once, in public.** The ARKit demo repository exists because one question kept arriving. A complete working example that people could clone answered it better than a hundred partial replies, and it collected its own audience. ## What it was used for The part that made the maintenance worth it was seeing where it ended up. Fictioneers built Wallace and Gromit: The Big Fix Up on it, a large scale augmented reality production for Aardman that went on to win industry recognition [2]. Genopets shipped a mobile game with Unity content inside a Flutter application [3]. Several other teams used it for product configurators and training simulations. Those are real products with real users, built by people who did not have to spend a weekend on platform views. That is the return, and it does not show up in the star count. ## What I would tell 2019 Publishing was right. By the measure of how many people used it, it is the most useful thing I have made [1]. What I would change is stating the supported configurations in the README from the first commit, and adding the reproduction template on day one rather than in year three. The obligation is real and it is not unbounded. Its size is mostly determined by how clearly you draw the edges early, and I drew them late. # References 1. Rex Raphael and contributors, "flutter-unity-view-widget: Embeddable Unity Game Engine View for Flutter", GitHub, 2019 2. Aardman Animations, Fictioneers, "Wallace and Gromit: The Big Fix Up", Aardman Interactive, 2020 3. Genopets, "Genopets: The Free-to-Play Move-to-Earn NFT Game", genopets.me --- *Unpublished draft. Not peer reviewed and not submitted to a venue.*