Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dumb ways for an open source project to die

nesbitt.io

Post reply on HN
Print view View original

121–130 of 155 posts

Re: Dumb ways for an open source project to die

#121

Post by marcus_holmes »

tamimio wrote: post #113
marcus_holmes wrote: post #99

Earlier quoted context omitted.

I work on a ton of different stuff, and this clause comes up for every job. I get them to remove it, or I don't accept the job offer. For me, this is a red/green flag on management. The clause is legal boilerplate, inserted because it's standard and they can. They don't actually care that much about anything you might build outside of work. If they won't (or can't) remove it then the organisation is inflexible and th…

> remove it then the organisation is inflexible and the people who are hiring me have no power within it Bingo. That’s my assessment as well, usually this stage is where any company tries to show their best behavior, good way to filter out the bad ones. But surprisingly it’s getting very common, contracts used to be before a one pager stating the salary and some other benefits, right now it’s a submission contract, a…

> contract I had with that company they refused to change anything justified by it being a “template”

yeah that's the thing. Firstly, that's not how templates work. Secondly, that's not how contracts work. And if they won't or can't change it, then what does that say about the rest of your experience working there?

As for non-competes. They are illegal in some places. And unenforceable. But there's a difference between "technically unenforceable" and "they're still going to take you to court and you have to defend that, which is expensive".

Re: Dumb ways for an open source project to die

#122

Post by dd8601fn »

Gigachad wrote: post #93
d1l wrote: post #81

Earlier quoted context omitted.

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 t…

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.

I recently made this mistake. It was my own fault.

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.

Re: Dumb ways for an open source project to die

#123

Post by jraph »

bruce511 wrote: post #119
prymitive wrote: post #26

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 simil…

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…

Free software licenses and open source licenses are almost the same set, and the difference between the two is not copyleft: the GPL is OSI-approved. The difference is in the spirit, focus, philosophy: free software is concerned about user rights.

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.

Re: Dumb ways for an open source project to die

#124

Post by xtracto »

prymitive wrote: post #26

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 simil…

You forgot the Open Core trap:

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.

Re: Dumb ways for an open source project to die

#125

Post by avaer »

marcus_holmes wrote: post #87
avaer wrote: post #35

Earlier quoted context omitted.

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 centr…

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

Thanks for the tip! I'm pretty jaded on social media but you gave me a spark of hope.

Re: Dumb ways for an open source project to die

#126

Post by whateverboat »

prymitive wrote: post #26

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 simil…

So what you are saying is that it has now become a professional industry rather than hobby stuff?

Re: Dumb ways for an open source project to die

#127

Post by killerstorm »

jonnyasmar wrote: post #63
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

The reality I keep running into: software that "just works for years" requires dependency hygiene at the ecosystem level, not just the application level. You can write Common Lisp or C or even most of Go that way and your code will still run in 20 years. The moment you depend on a modern frontend framework or even a modern backend one, you've committed to following its release cadence — which is often "we deprecate t…

The original Java standard class library is very capable, and you can do a lot using just 20+ years old classes. People responsible for Java platform design were thinking from perspective that software can be "done" and keep working for decades if not centuries.

But modern Java developers don't want to write this way, it's not "modern".

I guess incentives aka "job security" is the main force here. Would you rather say that a piece of software is "done" and can keep working for decades with only periodic maintenance required, or would you rather "we need to migrate from Quux to Baar as Quux is deprecated and unmaintained now, and Bazz might not be optimal from performance standpoint so we need a replacement. so yeah we'll be busy this year"?

And conference people are so helpful with "Baar is the only valid way to make Java now. If you think about rawdogging JCL you're a goblin"

Re: Dumb ways for an open source project to die

#128

Post by killerstorm »

Gigachad wrote: post #94
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

Anything connected to the internet or integrated with 3rd party systems will have to be maintained regularly forever. Anything that is self contained will last forever. Main reason I avoid buying anything that requires an app. Because one day that app won't be maintained anymore and it just wont work, bricking the hardware in the process.

Well, kind of, but I'd think over 30 years people would notice this problem and figure out how to factor out "internet" part from business logic part. (And you might want formal verification / memory safety / etc, so you can accept arbitrary inputs.)

But on contrary, business incentive is to make "everything app" which needs to be continuously patched.

Re: Dumb ways for an open source project to die

#129

Post by killerstorm »

chamomeal wrote: post #85
killerstorm wrote: post #32

It's ridiculous that everything is expected to be maintained on a weekly basis. In the past we had software stacks where once code is written it's just done, it will keep working years and even decades later. E.g. https://sapaclisp.common-lisp.dev/ you can download code written in 1993 and just load it in latest SBCL.

Different languages definitely have differently expectations and cultures around this stuff. If an npm package hasn’t been updated in 2 years, I’m suspicious. I’m gonna check the downloads, check GitHub issues and stuff to see kind of problems people are having, Google around to see if people are using something else. If a clojars package hasn’t been updated in 6 years, I don’t even think about it!!

npm package can contain binary code... it's an absolute disaster of an ecosystem, driven by "it works on my computer" and "I can build an app in 10 minutes!"

Re: Dumb ways for an open source project to die

#130

Post by chii »

jonnyasmar wrote: post #55
prymitive wrote: post #26

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 simil…

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 proble…

> work of running an open-source project (issue triage, security disclosures, contribution guidelines, CI, release cadence, dependency maintenance)

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.

Post reply on HN