← Back to context

Comment by prymitive

7 hours ago

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

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”

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.

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.

  • Do you all really have your random public git repos accidentally being used in production by Facebook? No one’s ever made one of my one-commit git repos a key component of corporate infrastructure.

    Or do you mean that the meaning of what it is to “publish” something has shifted?

    • Exactly, I’m confused why people are feeling obligated to put more effort than they have interest for these projects. If Facebook did start using my project in production, then that would of course be their dumb decision that they would be responsible to fix!

  • I still publish everything. If someone wants to come and ask me to do something they can happily find out I likely will not.

  • > 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.

    • Love this. Gonna add it to a few of mine that are quasi abandoned because I'm too burned-out to wade back into them in any detail, per one of the categories described in the article.

  • > 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.

    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.

    [0] https://marlam.de/msmtp/download/

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.

  • This is why is like pure C/C++ projects with zero dependencies beyond the standard library, and this is certainly what I do for my numerical work. If some external library is needed, the source files of the dependency are downloaded, compiled, and kept as part of the project itself, so that it can always be rebuilt and reused if necessary. Of course, depending on what you do, this may not be practical, although LLMs certainly have made it much easier to generate the dependencies in house, so to speak.

  • Do the versions of the dependencies that you used no longer exist anywhere?

    • they exist, but they are likely unmaintained, and may have known security issues.

      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.

    • Fair counter, and that's the right stance. The tax I'm pointing at is the implicit social one: feeling like you owe a response. Plenty of publishers get burned out before they figure out your model.

    • In my experience, the most common problem is that a dependency changes. It drops support for something, API changing, etc. If it's 3 dependencies deep, and one of the deps in the middle isn't maintained anymore, well...

> 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

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.

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.

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.

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

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.

  • The signal of quality for me is the number of contributors and the age of the repo. If I see a repo that's several years old and has many contributes over that time it's very likely a reputable project with some value. If I see a 1 month old repo with one user who has dumped the whole thing and then done nothing since, it's likely vibeslop that will be abandoned in a month.

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.

  • I found Mastodon, feels like usenet in about 1993.

    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 :)