Greybeard here... let me start by saying I like the cut of the author's jib. I'm old enough to have sat before the elders of the arpanet when there were only 1's and they had to forge about half of them into 0's manually. Another thing about the old ways of making software is projects were often written or maintained by one or two people at a time. The intarwebs at large had their email addresses and mailed them bug reports directly. Some projects got discussed by the community on IRC or mailing lists. People were generally professional and if they weren't they were deleted from the mailing list or added to people's block files on iirc and pine.

But my point is... the active dev group was, at any time, very small. Mostly I'm talking about small utilities like make, Sendmail, sed, awk, sed. Perl seemed like it was just Larry Wall and tchrist for most of the time before 1990. gcc was an insane counter-example with a cast of thousands who submitted patches and you had to socialize your patch w/ RMS if you wanted it upstream.

oh wait... I forgot to make my point... My point is... the new tools support larger teams of people constantly interacting. I think there are great benefits to having a small team and effectively giving the middle finger to internet randos who don't submit their patches on one of their kidneys (i.e. - they'll think long and hard and sure as he'll won't submit two.) But getting people interested in your work output isn't one of those benefits. So... absolutely... go old school... But keep in mind the size of your team will be small and it may be hard to attract users.

But... screw users... I write software to support my own use cases. I open source it on the off chance someone else may find it useful.

I laughed at “back when there were only 1’s and they had to forge about half of them into 0’s manually.” Stealing that one.