The framing assumes the ratio of "problem-and-solution" projects to "personal-brand" projects has shifted. I'd push back: I think the underlying ratio is roughly the same — what's shifted is what gets published.

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.

You're not wrong, but the License used is critical here.

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.

Dependency bloat and dependency bitrot have made solutions less permanent, have increased the maintenance burden. My ancient projects with zero dependencies still stand. But projects I built on shifting dependencies are rotting and cracking.

> Call me old but there was a time when “open source project” meant “I had a problem, this is my solution, if someone has the same problem then you are free to use my solution”. These days is more: - building personal brand - showcasing your skills - trying to outsmart somebody else, often because they didn’t merge your pr - sometimes just having fun

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

And there was a definite shift from sharing toward evangelism.

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.

Mostly because CS career advice was always "have some personal projects to show off". Either fully single-person, or be a contributor. And over time, it has soaked some of the corporate, CV-driven development culture as well.

I imagine there's a similar same number of those style projects out there.

However, the amount of devs have grown exponentially, and the number of non-niche problems without a solution have dramatically decreased.

Its also become lots of people demanding fixes but not many contributing them.

15 years ago GitHub was a strong signal for like-minded devs who were of the “let me code and slide pizza under the door” variety. The signal became less meaningful over time so people started optimizing for other things…stars, whatever. Brand. I think the venn diagram of front end marketing types and the explosion of js frameworks probably was the driver for this. Now with vibed out projects everywhere it’s a real task to separate the wheat from the chaff. And I still use gh because I imagine those stars are still current in some markets but maybe I’m deluding myself.

Or, Perhaps the invention of the rocket emoji most likely was the cause of this phenomenon.

> 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”

where do people get this idea? AFAICT it's made up.

There was a time when web meant sharing your hobbies with supportive anonymous strangers, a time when crypto meant doing clever things with numbers.

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.