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

141–150 of 155 posts

Re: Dumb ways for an open source project to die

#141

Post by bruce511 »

jraph wrote: post #123
bruce511 wrote: post #119

Earlier quoted context omitted.

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

Exactly. If you care about "who" uses the code then Free software certainly helps to limit that.

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.

Re: Dumb ways for an open source project to die

#142

Post by killerstorm »

lmm wrote: post #111
killerstorm wrote: post #57

Earlier quoted context omitted.

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.

I don't think so. Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.

Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all data).

The main problem is that there's no incentive for software vendors to separate parts: e.g. app which processes financial records might also send/receive data over internet. If user had a more explicit control over flow of data (e.g. imagine n8n style pipeline) many logic flaws like sending data to wrong place could be eliminated.

It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.

Re: Dumb ways for an open source project to die

#143

Post by chmaynard »

Lammy wrote: post #23
chmaynard wrote: post #12

Then there's Jekyll, which is not exactly dead but definitely moribund. It seems to be blocked by GitHub's refusal to support further development and upgrade to the 4.x releases.

Ignoring the GitHub Pages issue, What does Jekyll 4.x not-do that you want it to do?

Two things come to mind:

    - No support for Liquid 5.x (see GitHub issue #8535)
    - SQLite not a first-class data source (workaround: a 3rd-party plugin)

Re: Dumb ways for an open source project to die

#144

Post by em-bee »

sbinnee wrote: post #89

I must admit that I have a few thesis orphans. I didn't think them this way that they are my children. But in some sense, they are! I am feeling a bit ashamed.

it is unfortunate the there is little motivation to publish thesis projects to a wider audience. not to blame the authors here, because that is how the system works. exceptions require extraordinary effort or extrinsic motivation.

one project i am working with got a grant that was conditioned on the project being published as open source. it motivated the developers/researchers to reach out to the wider community and even package the project for a linux distribution. that's how i was able to find out about it. i got involved and i am still using it 20 years later. but without that grant this likely would not have happened.

Re: Dumb ways for an open source project to die

#145

Post by em-bee »

rurban wrote: post #131

Good list, but the most dumbest way was how perl11.org died. The guy who paid for the domain, didn't pay the domain fee anymore without telling anyone else. So we lost it. And then gave up.

FOSS projects should register their domains with providers that allow anyone to pay the fee for a domain, even if they don't own it. then, instead of depending on one person, anyone in the community can pay directly to ensure that the domain is renewed.

Re: Dumb ways for an open source project to die

#146

Post by foxglacier »

to11mtm wrote: post #41
foxglacier wrote: post #24

Earlier quoted context omitted.

It sounds like the maintainer you're describing was underhandedly helping their users with the silent expectation that they also contribute back to the project and got bitter when it didn't happen that way. Open source is altruistic, remember. You explicitly tell the world that you are happy for anyone to only take from the code what they want for their own needs and never contribute back. If you don't want to help u…

I think I know the pattern they are describing, and it's a semi-unfortunate one. People make a fairly-complex open source thing. Due to the complexity for certain environments/cases, the author(s) have a commercial support option. Consumers from bigorg use it, and wind up opening issues wanting free help for their niche use case, no they don't want to get a support contract, but this subset of the user base causes a…

It must be having their mindset set wrong for the situation. Are they a business out to make money? Then suck it up and accept they have to smooch their leads to convert them into paying customers. Or are they trying to build a community of altruistic developers and helpful users? Then just ignore any support requests that are too much. It's pretty common for open source devs to just leave issues sitting around without even acknowledging them or to close them without any comment.

I might be biased though because I enjoy helping users. I also sell commercial support for my software and sometimes both paying and unpaid users have big niche requests that go too far for my liking so I stop helping them on that. Sometimes I do feel bad that I spent so much energy on them but it's not bitterness and I blame myself for not saying "no" sooner, not the customer for simply asking. People are allowed to ask for things.

Re: Dumb ways for an open source project to die

#147

Post by lofaszvanitt »

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…

This is how programmers use to force to work for companies if they want to earn a living. Time to fight back.

Re: Dumb ways for an open source project to die

#148

Post by wging »

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…

Many OSS licenses are also free software licenses, even if they are not viral and don't impose severe restrictions on the licensee in the way the GPL does. The MIT license, for example. "Free software" and "GPL" are not synonymous, even GNU doesn't say so. See https://www.gnu.org/licenses/license-list.html#SoftwareLicen...

Re: Dumb ways for an open source project to die

#149

Post by lmm »

singpolyma3 wrote: post #133
lmm wrote: post #110

Earlier quoted context omitted.

Until you run out of hardware that can run an OS old enough that the old version of the framework works, sure. Even then, you may find it hard to add new dependencies without getting current on the framework, since most ecosystems require you to pick a winning version in the case of a "diamond" transitive dependency.

Well if you're adding new dependencies you're already doing new maintenance work and this is a while different ballgame than just to keep what you have working.

Yes and no. In practice sooner or later you need to update something - you need it to work with a new OS/database/TLS algorithm - and then often there's a domino effect.

Re: Dumb ways for an open source project to die

#150

Post by lmm »

killerstorm wrote: post #142
lmm wrote: post #111

Earlier quoted context omitted.

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.

I don't think so. Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE. Flawed business logic might corrupt data, but that's much less rare than security vulns, and might be solved by versioning data (e.g. copy-on-write, even Windows had Volume Shadow Copy service which can take a snapshot of all…

> Business logic just works with data it has access to. Backup, encryption, access control can be separate concerns. A good programming stack would make sure you don't have RCE.

The problem is that the business logic tells everything else what to do and has authority to do everything that the program can do. Exploiting that way is fiddlier (it's like doing ROP only more so), but ultimately once the software gets into an unintended/unexpected state it's game over.

> It's just that we are used to coarse-grained permissions and abstractions defined back in 1970s. E.g. an app gets access to entire network stack and then can do anything - send telemetry, spam, download code, etc. If we had more high-level comms layer on top of app it could be much more inspectable.

Many have tried. If you try to require fine-grained permissions and user in the loop people just say yes to everything. Ultimately the user thinks they want to do the thing they said to do, and asking them again won't change that.

Post reply on HN