from Hacker News

How we manage 200 open-source repos

by nathanwallace on 10/6/23, 12:07 PM with 32 comments

  • by samspenc on 10/6/23, 9:05 PM

    This was actually a worthwhile read, sharing the section titles in case anyone is wondering what they are getting into:

      Lesson 1: Respond instantly
  Lesson 2: Early communication is essential
  Lesson 3: Treat contributors like team members
  Lesson 4: Age reports keep you honest
  Lesson 5: Burndown is a must
  Lesson 6: Consistency is the name of the game
  Lesson 7: Documentation is king

  • by bzbz on 10/6/23, 9:12 PM

    I was skeptical when the author implied automation was the solution.

    But actually, the given solutions are mostly communication-focused, and the automation is to aid in that.

    Good read.

  • by dsp_person on 10/7/23, 6:46 AM

    A question for people here saying "use a monorepo", and coming from a different direction than that of the article. Say I want to use a monorepo for all code I write for personal use and development, but I'll have a folder with dozens of projects cloned from github often with small tweaks and custom branches. Is the solution submodules? Saving patches or just code-snippets in the monorepo and keeping the random misc repos isolated? Hardlink specific files of interest?

  • by manapause on 10/6/23, 10:24 PM

    Steampipes is amazing. It is a light in the darkness to anyone taking on enterprise compliance reporting. The growth of the platform laterally WRT plugins and features while somehow making cross-org/multi-account even easier for end-users on top of building a cloud-hosted solution for teams is a testament to everything in this article.

  • by jenadine on 10/7/23, 5:51 AM

    Another question worth asking is whether 200 repos are worth it. Wouldn't it not be more efficient for everyone involved to merge them all in a single mono-repo?

    That said, the tips is that article are equally valid for single repositories.

  • by IshKebab on 10/7/23, 6:30 AM

    Using 200 repos is just creating unnecessary problems. Use a monorepo.

    That said, all the solutions are applicable irrespective of how many repos you have. First I'd heard of an "age report" too. I like that idea. It's too easy for bugs to be marked low priority and then never get fixed.

  • by valyala on 10/7/23, 9:33 AM

    The blog post contains very valuable advices!

    I'd recommend also shrinking the number of repositories - this can significantly reduce the amounts of efforts needed to sync changes, which span multiple repositories. Ideally there should be a monorepo, where any change can be put in a single atomic commit, even if it touches the core part of the code, which is used in thousands places of the rest of the code.

    Another recommendation is to keep user docs in the same repository as the code - then docs can be updated synchronously with the code in a single commit.

    We at VictoriaMetrics are following most of the recommendations from the blog post, plus we try minimizing the number of repositories in order to reduce maintenance burden as described above.

  • by raybb on 10/7/23, 6:05 PM

    A little late to the reply here but I'm a volunteer for openlibrary.org and I think they'd benefit from trying some of these things so I might share it with you.

    What tool are you using to make the age reports? How do you determine if it's waiting on the submitter or the reviewer? Is it based on last comment? or requesting a review, etc?

    There once was a tool similar to this that github bought and it was quite nice even for a small internal team but I'd really like to know what works well at your scale.

    Cheers!

  • by haarolean on 10/7/23, 2:46 PM

    As a maintainer I feel like the first tip is not the best approach sometimes. People tend to raise a lot of “I got a problem” issues (well, we all do sometimes) which they solve themselves in a short time (e.g. a misconfiguration). Responding instantly to such sounds inefficient.

  • by jgeurts on 10/8/23, 3:57 AM

    Curious what tool(s) you use to format sql?

  • by vinnymac on 10/7/23, 12:25 AM

    In addition to this communication guidance, I prefer when issues are disabled entirely. I would like it to be the default.

    I am also looking forward to seeing LLMs applied to this space.

    Plenty of problems could be solved with some simple research and understanding of the code in a project. If that could act as a barrier between those with issues and those who contribute, I imagine it would help a lot.