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

111–120 of 155 posts

Re: Dumb ways for an open source project to die

#111

Post by lmm »

killerstorm wrote: post #57
cebert wrote: post #34

Earlier quoted context omitted.

Different times. The need to patch for security updates alone is increasing rapidly.

The need for security update is largely due to poor development practices where safe and unsafe code is mixed together, lots of dependencies with unclear provenance and quality, etc. We had a recipe for a much stabler stack decades ago: separate runtime (might need to be patched regularly) from a high-level business logic (never needs to be patched if done properly). E.g. old way of developing web front-end was like…

Separating the runtime from the business logic doesn't really work because the business logic has the authority to do anything it has the authority to do. It's the https://xkcd.com/1200/ problem all over again.

Re: Dumb ways for an open source project to die

#112

Post by josh3736 »

tamimio wrote: post #64

Very good list, I have seen most in action. I would also add AI where some people just make their own internal tools rather than making it open source to everyone. > Apple is the classic example of an employer that simply doesn’t let most staff do outside open source I have been encountering this a lot recently, and I don’t know why. Last one a couple months ago, a company wanted to hire me for some work and while al…

> the company prevent you from working in any open source work, including personal ones without a written permission, and everything you do will be the company property on or off duty

PSA: If you're in California, these kinds of employment contract terms are (mostly) illegal and unenforceable.

Labor Code 2870 outright invalidates any employment contract provision which attempts to claim ownership of IP rights to anything “that the employee developed entirely on his or her own time without using the employer’s equipment, supplies, facilities, or trade secret information” unless it relates to the employer's business or results from other work performed for the employer.

Labor Code 96(k) prohibits employers for disciplining or firing an employee who engages in “lawful conduct occurring during nonworking hours away from the employer’s premises,” with an exception for contracts that prohibit conduct by the employee that is in direct conflict with the employer’s “essential enterprise-related interests.”

So blanket prohibitions are out. If you're doing something that closely relates to your employer's products/business or could be construed as a conflict of interest, that's when you should consider written permission, but a company can't say “no” unless it actually relates to the company's business.

California is relatively unique in these worker protections, and they're a big reason why Silicon Valley became what it is.

Re: Dumb ways for an open source project to die

#113

Post by tamimio »

marcus_holmes wrote: post #99
tamimio wrote: post #64

Very good list, I have seen most in action. I would also add AI where some people just make their own internal tools rather than making it open source to everyone. > Apple is the classic example of an employer that simply doesn’t let most staff do outside open source I have been encountering this a lot recently, and I don’t know why. Last one a couple months ago, a company wanted to hire me for some work and while al…

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, and setting up the power dynamics before you even do anything. Another contract I turned down was also full of questionable clauses (like you should work more than 48h a week when needed, overriding the common law with maximum 48hrs, and up to interpretation: “needed”), and none of the benefits discussed were written there, not even a reference to XYZ internal policy or similar, meanwhile, they had so much written against you not just while doing the work but even after you leave, that they could ruin your future career if they chose to. I believe there should be a federal centralized system govern these contracts and ensure each contract is in compliance, easy to implement by having a contract builder that add clauses to it while giving margin to each party to customize other clauses to their liking. Otherwise, a lot of people will get exploited, that contract I had with that company they refused to change anything justified by it being a “template”.. it doesn’t feel like a contract anymore since contracts are made to be negotiated, it feels like signing up for a SaaS service where if you don’t agree to the entirety of it, you are out, except for jobs you’re not the customer.

Re: Dumb ways for an open source project to die

#114

Post by serf »

leaving a repo unattended because you have shit to do isn't a 'dumb way' for it to die. that's life.

I didn't sign up as maintainer for life just by simply throwing something on git -- i'm not using git as a resume builder, I use it as a code repository.

The problem is that people (and the whole fucked up industry and convention-system itself) seem to conflate github with linkedin.

Re: Dumb ways for an open source project to die

#115

Post by dlenski »

This is a great article and a great taxonomy, but I dislike the title.

These seem like the normal ways that an open-source project fades and dies.

There are also several routes by which a project can be revived and reinvigorated. One of my favorites, because it's so obscure and also because I started the Wikipedia article on it, is https://en.wikipedia.org/wiki/Slirp#User-space_networking_an...

Re: Dumb ways for an open source project to die

#116

Post by dlenski »

david_allison wrote: post #86
jonnyasmar wrote: post #55

Earlier quoted context omitted.

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…

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

Re: Dumb ways for an open source project to die

#117

Post by drnick1 »

fritzo wrote: post #39
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…

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.

Re: Dumb ways for an open source project to die

#118

Post by busterarm »

With what's been happening lately I've been thinking of just releasing anything I work on with what I call the Goro Maki License.

The entirety of the license is four words: "Do As You Like". There's no expectations and no promises. Here it is. The author jumped off their boat. The code's future is up to you.

Re: Dumb ways for an open source project to die

#119

Post by bruce511 »

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

Re: Dumb ways for an open source project to die

#120

Post by simonkagedal »

usernametaken29 wrote: post #14

I remember having this discussion a long time ago that instead of dependencies we should build a function and type hub that lets you pick tested function and type definitions. Each individual artefact is tiny so forking it is really simple. Instead of building a massive library you mix and match for your use case. The platform itself can host test cases decoupled from the definition. With AI this sounds much more rea…

Sounds a bit like the idea behind shadcn/ui. You start from the generated components, but the idea is to fork the code.

(Then they seem to also have added their own kind of dependency management thing to update components, which seems to me to kind of defeat the purpose..)

Post reply on HN