And if you work for big org it’s also often “this looks vaguely similar to one of our epics so let’s start using it and demand 24/7 support”
And if you work for big org it’s also often “this looks vaguely similar to one of our epics so let’s start using it and demand 24/7 support”
The work of running an open-source project (issue triage, security disclosures, contribution guidelines, CI, release cadence, dependency maintenance) is way higher than the work of solving the original problem. People with the "here's my private workflow tool" mindset increasingly don't publish at all because they can't afford that tax. Meanwhile, anyone seeking brand-building benefits IS willing to take it on, because the brand-building is the point.
So the visible OSS landscape over-represents the brand category not because solution-sharing died, but because solution-sharing acquired a 10x maintenance overhead that most people now opt out of. I see it in my own dotfiles — full of small tools I'd happily share if "share" still meant "drop a gist." It doesn't, anymore.
It still does. Feel free to use https://unmaintained.tech/ on your repo.
Or do you mean that the meaning of what it is to “publish” something has shifted?
Some tools I use, like msmtp[0] just publish tarballs and maybe have git repo browser. I strongly believe that github is a tarpit for opensource work. Especially when a new developer is brainwashed in behaving like they’re a business under contract.
so why not just simply dont do any of that? Ignore issues, ignore security disclosures, etc. The end user is responsible for auditing their own security needs, and does not have a right to free audits from an open source tool.
i have a project that suffers from that. the version of a library it is built with is old and unsecure, but the newer supported version has a completely different API that would require me to rewrite the code that uses the library.
i had a second such case where i discovered a fork of the old version of the library which was still maintained. otherwise there too a rewrite would have been required.
For example C was shared, C++ was evangelized. The difference is the effort put into convincing people to adopt your stuff.
Java for instance was mega evangelized, Sun thought it might reverse their fortunes.
Linux was initially “here you go, hope it works for you” but then it attracted many people who decided to create an ecosystem around it.
Linux, MySQL, PostgreSQL, Apache, Python, most web browsers, and large swaths of server code used across the internet have been "open source projects" for years that were more than people sharing their solution as-is. Useful projects have always developed communities.
Some people do try to make open source projects for exposure or resume content, but that's usually orthogonal to the projects that get enough traction to have to worry about maintainers disappearing.
I think you're mixing two different concepts up
In my experience you can pretty much always bet on greed, money, and psychopathy to ruin anything that reaches beyond Dunbar's number.
It's sad when your playground gets overrun by drug lords (metaphorically speaking); I don't really have an answer to that. It's my central trauma.
There are odd corners of the web that still work on RSS, and just have people sharing stuff.
But yeah, the entire of mainstream internet discourse can be safely ignored.
HN, though, I still like it here :)
However, the amount of devs have grown exponentially, and the number of non-niche problems without a solution have dramatically decreased.
Or, Perhaps the invention of the rocket emoji most likely was the cause of this phenomenon.
Went looking for a thing, saw some Reddit chatter, decided to try it out.
After all the setup and such I realized it was vibecoded and poorly designed. Just monster gaps they obviously didn’t think about and can’t realistically fix.
I should have paid closer attention. Checked the repo… couple months old, no real activity after the first week or so, basically the only project on the account, issues were all unanswered references to the nasty gap in the design.
If the code is indeed Open Source, with an OSS license, then you can use it as-is, or just learn from it and write-your-own. You might even fold it as-is into your app. Keep the code, but remove the dependence.
Free Software on the other hand is a different animal. The GPL et al is viral. Doing any of the above with GPL software has consequences. Even learning and rewriting is risky- the rewrite better be more than just variable name changes.
If you're old school, and you want to share on a "do what you like, I'm not turning this into my day job" basis, where you want folk to actually benefit, yhen I recommend an OSS license over a Free license.
On the other hand if your target audience are other Free developers, then a Free license makes complete sense. And if you plan to commercialize your project down the road an aggressive Free license (like say AGPL) is a good choice.
Ultimately your choice of license should match your goals.
And if you care about user rights, use a copyleft license to prevent someone from building a proprietary derivative, even if you are not turning it into your day job. Especially if you are not turning it into your day job, a copyfree license is more likely to atract corporate.
If all you want is to offer "here's some code, knock yourself out" then a license like MIT and BSD is generally more useful to more people.
where do people get this idea? AFAICT it's made up.
Company wants to get customers so it lures them into an almost-useful "open source" application that happens to be unisable when wanting to do anything serious.