Hacker News Reader

Comment by siva7 | Hacker News Reader

I get anxiety publishing open source because of things like this.

The one GitHub repository of original work I publish right now is kept in Archived at rest; I unarchive it to push commits and then rearchive it, every time. It has been perfectly quiet and my anxiety associated with working on it has dropped to zero. Highly recommended.

Can't you just disable issues?

I've seen DRF did that. Not sure if that is not possible for normal accounts.

I couldn’t when I started out doing that. But I don’t want PRs, either, so this works out for the best: I contribute a benefit and if someone forks it then I can consider merging their work unbothered by their expectations that their ‘request’ be granted.

You can disable PRs as well

Overlooking your repeated assumptions of my incompetence at GitHub administration, neither of the 'why not just' steps you countered with will result in the banner that says 'This project is archived', which is a key component of my intentions. (For those who overlook it, the other characteristics of archival of course still suffice; I get all three for one UX interaction rather than three!)

Which of these projects is more likely, relative to the other in its pair, to be targeted by users whose expectations are presented disrespectfully by whatever means (let's assume email) the users can discover?

1a) A project that has recent commits, but has pull requests and issues disabled.

1b) That exact same project, with the banner "This repository was archived by the owner" shown on all pages and objects within it.

2a) A project that left a work in progress unfinished six months ago, but has pull requests and issues disabled.

2b) That exact same project, with the banner "This repository was archived by the owner [six months ago]" shown on all pages and objects within it.

As one can reasonably predict, archiving when I'm not actively pushing commits turns out to be an effective way to stem the tide of jerks who otherwise pick a fight by email/irc / discord/forum / blah/blah / etc., in hopes of persuading me to commit further resources to their unpaid benefit or to finish something I don't care to work on finishing right now / this week/month / quarter/semester / year/decade / ever. It's archived, so clearly it'll never be finished, which helps enforce an appropriate calibration of expectations upon those desiring the outcome — and if I someday finish it, hooray, but no one has any plausible way to justify any expectations to the contrary, no matter how hard they wish otherwise. Thus why I recommend using archiving to remove the social pressure component of working in public on GitHub.

Of course, if you have a better solution than you've offered so far here, I'm certainly willing to consider it.

You could add your own banner that makes it clear what the status and expectations of the project are. In fact, that is probably a valuable thing to do if the project is archived too.

If you archive it, then sure user's are less likely to send you disrespectful messages by whatever means (assuming they can find such means), but they are also less likely to use it, because you have basically said "this project is abandoned". Which if you don't want users at all, I guess that's fine, but then I'm curious why you bothered to publish it publicly at all.

The thing I’m publishing is currently the only public source of that information and code worldwide. For those who need it, there is literally no competition, unless someone else opens Ghidra and reproduce my efforts over several long years from scratch. I don’t publish because I want to play numbers-go-up with the world population; I publish because I invested years of research for my own benefit and wish those who come after me to have a starting place further along than where I had to begin. Sure, it’ll benefit users, but ‘on the shoulders of giants’ only works when you publish at all.

There are only maybe a few thousand people at most worldwide who could benefit from what I’m doing, and only 1% of them might actually go looking for this. Can you imagine working as an open source maintainer on a project with a hard cap on audience size of a hundred people? Seems fine to me; I’m one of those hundred, after all :)

Try publishing on https://repo.or.cz (or another old-style web interface), and just leave an email for contact.

You will hear only crickets.

Adding the slightest friction, and making potential drama 1:1 only, demotivates most people.

You might miss out on an occasional good feedback, though.

I don't have my stuff on GitHub, but git push will send me email with a patch. I actually get real, useful patches out of it (more than before I had only email); not huge stuff, but scratching people's itches and bugs; stuff I can mostly just apply right away. I never get pure junk (e.g. the “I'm sure you want to switch to My Favorite Build System” patches, or AI slop). So somehow, for me, this is pretty much the perfect level of friction, it seems.

This is the way. You can also just decide to not accept contributions and feedback in general.

Further downside is that your project will have a harder time becoming popular, and being popular is secretly (or not so secretly) the motivation for many in open source.

Will be a lot more honest though.

Reply on news.ycombinator.com