If people ever wonder how this happens... let me tell you this is the organic evolution for giant multinational corporations. You have thousands of teams doing some computer stuff. And never, ever will it happen that responsibilities and product design get clearly cut for the hot ai stuff. At least hundreds of teams will fight to own a part of this "copilot" thing which leads to over a hundred new products named copilot. It's not just Microsoft, every single one of the big boys does this. You can't escape it. You know why? Because they all know the alternatives are even worse.
That's a bad analogy you made. Copilot is a Product Platform, Save is a basic software function that even my grandma could explain what it does. You don't have to believe me, test it yourself: Let your grandma explain what save does in Microsoft Word or Excel. Then let her explain what Copilot does in Outlook, VSCode, Bing, Github Copilot, Bing, Sharepoint, Microsoft 365 and so on..
I don't think you've done any of that - at least not for a successful open source project. The topic here is about open source volunteers and not your day job.
Don't take it personally but the people here are talking about open source projects and unpaid work in their free spare time. There is zero value you could share in this thread from your experiences on developing closed source business products because it completely misses the topic of volunteer work.
He's making a general point about "regardless of how something is presented to you, at the end of the day you have to look at the actual information, and if there is some truth in it, then it would be illogical to dismiss it".
at the end of the day you have to look at the actual information, and if there is some truth in it, then it would be illogical to dismiss it
sure, but the amount of nonsense (to avoid the b-word) i am willing to put up with depends on the amount of money i expect to make from the project. for unpaid work that amount is zero. if i am investing my free time and i allow you to benefit from it, you better be nice when you talk to me.
when i run a business then the information gained potentially makes my product sell better. for a volunteer project i may not care about popularity, so the information gained is not necessarily of any benefit.
I will listen to a rude paying customer if I must, because my income will be tied to it. If a similar paying customer comes and they are better behaved, the rude customer will take second position.
On an open source project that I’m doing for my own enjoyment rude people are not welcome. I’m doing that for my own enjoyment - to decompress after dealing with rude people. Close issue, won’t fix, ban free user.
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.
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.
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.
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.
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.
Came here to say the same. I remember the discussion on HN back then where we discovered that an official from Anthropic made clear that claude -p was still okay.
> Our documentation was already indexed, chunked, and stored in a Chroma database to power our search, so we built ChromaFs
It's obvious by that sentence that these guys neither understand RAG nor realized that the solution to their agentic problem didn't need any of this further abstractions including vector or grep
reply