A Sad Day for Rust • Hacker News Board

Re: A Sad Day for Rust

#441

Post by ckdarby » Fri, Jan 17, 2020, 5:25 PM UTC

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> Open source participants are volunteers and owe you nothing.

Equally, someone gets hit by a car while crossing the road. I don't owe them anything to go help them but society, morality and being decent are these unwritten rules that kind of do force you into owing something.

Yes, I agree, volunteers don't owe anything but there are some unwritten rules that when broken should be frowned upon and I'd probably go as far as saying should be held against them.

As a reader of this, you could be thinking, wow this sounds extreme but here is the easiest example I can give.

- Someone writes library

- Library comes insanely popular

- Author refuses to allow the community to take over original project

- Author wants to maintain status, ownership, etc

- Entire community now suffers because the author doesn't owe anyone anything

"Just fork the repo", is the most common response but let's be real, nearly nobody uses the forks and every other repo that uses this popular library is using the non-forked repo.

Re: A Sad Day for Rust

#442

Post by [deleted] » Fri, Jan 17, 2020, 5:25 PM UTC

throwlaplace wrote: post #163

izacus wrote: post #145

Earlier quoted context omitted.

> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

no your argument isn't useful. the question is never about rights because we all know what the maintainer's rights are (so it's always a discussion of obligation). if you accept that the open source projects are voluntary as an axiom then you in fact cannot criticize choices made by the volunteer. here's an analogy: a homeless person asks for money. you don't give him money but buy him food. can the homeless person r…

[deleted]

Re: A Sad Day for Rust

#443

Post by adonese » Fri, Jan 17, 2020, 5:25 PM UTC

endothrowho333 wrote: post #21

> “Why Reddit is like this” is a whole other essay; I think it’s built into reddit’s structure itself. Classic Eternal September. Around 60k subscribers, the cultural identity starts degrading, as the amount of "old guard" is outmatched by "new blood." Therefore, the old "monkey see, monkey do" phenomenon, where new users would slowly mimic the culture of the prevailing older users to "fit in," is replaced with new u…

Not to compare or anything. But I’m active at r/Golang and I find that the community is comparatively better there. I was shocked as to how would someone told anyone to never write a code again!

Maybe this because some members on Rust subreddit believes that they are more intellectual than others? It seems like a cultural thing, go people don’t bother to be seemed as smart or so and that’s possibly reduce the aggressive competition that naturally arise in places where intellect, high performance etc are very important metrics?

Re: A Sad Day for Rust

#444

Post by rukittenme » Fri, Jan 17, 2020, 5:25 PM UTC

I want to add two (maybe very) controversial comments.

1). It should be considered RUDE to contact a solo maintainer in any way relating to the project (email, issue, pull request, etc.). You should ALWAYS fork the project and use the forked project on your own terms.

Most people write their projects, on a whim, on a Saturday, for a bit of fun. They do not want to be shackled to a hobby for the rest of their lives.

2). Opening an issue and opening a pull request are IDENTICAL requests for effort.

Think I'm wrong? How many people were so incensed by this renegade maintainer that they FORKED the repo?? Why didn't people FLOCK to the safer fork? Why did people still care about the original repo??? The answer to those questions underlie the fundamental problem of open source. No one wants to do the work. People want to work on what they're passionate about. But they don't want the responsibility of ANOTHER FULL TIME JOB.

An issue is a request to write "native" code. A pull is a request to maintain "foreign" code. I have never had a large, successful open source project. To date, I've had one repo with ONE issue and ONE pull request. Both required more effort than I ever wanted to give.

I have stopped opening issues completely. If a project is maintained by one person, you will never hear from me. Large projects with paid maintainers will receive issues because I believe it the only appropriate time to do so.

---

Here is a simple flow chart for contributing to a solo maintainer's open source project.

1. A problem has been discovered.

2a. I do not know how to solve the problem. -> Move on. Don't reach out to the maintainer in any way.

2b. I can write a fix for this problem but I don't want to maintain this project in its totality. -> Move on. Don't reach out to the maintainer in any way.

2c. I can write a fix for this problem and I want to maintain this project in its totality. -> Fork it. Don't reach out to the maintainer in any way.

Re: A Sad Day for Rust

#445

Post by fnord77 » Fri, Jan 17, 2020, 5:25 PM UTC

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

> It was never Nikolay's job to vet actix-web for you

Imagine if the linux maintainers took this attitude.

This attitude severely undermines the credibility of opensource.

If users of opensource libraries can't have confidence that those libraries are written correctly, we might as well all go back to commercial software.

Re: A Sad Day for Rust

#446

Post by scarejunba » Fri, Jan 17, 2020, 5:26 PM UTC

Dudes, why don't you just fork the repo and run with it. License looks good.

It doesn't matter if code is full of secbugs, author doesn't like patches, or whatever. Code is open source. You can't make it look like your vision. Fork it.

Of course, no one in the mob appears to have had the wherewithal to do that.

Re: A Sad Day for Rust

#447

Post by HorstG » Fri, Jan 17, 2020, 5:26 PM UTC

izacus wrote: post #145

deng wrote: post #100

Earlier quoted context omitted.

As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you.

> As a maintainer, it is his choice which patches to accept. If you're not happy with his decisions, choose another project, fork it, or pay someone to do it for you. Sure, but that DOES NOT mean you're immune to criticism, especially when it comes to security. Your type of argument could otherwise be used for pretty much everything - even large corporations. It's not useful.

Security isn't a special license for being nasty. Criticism is fine, even with some urgency due to security being important.

But software done for free by volunteers carries no obligation of a legal or even a moral kind, whatsoever. This is completely different from selling software or doing work for hire or donations. There a moral and often even legal obligation exists.

Re: A Sad Day for Rust

#448

Post by skywhopper » Fri, Jan 17, 2020, 5:26 PM UTC

ddevault wrote: post #38

A lot of this thread has it wrong, and this wrongness contributes to the problem which led to this. I have two simple mantras which establish my philosophy here: 1. YOU are responsible for your dependencies. 2. Open source participants are volunteers and owe you nothing. It was never Nikolay's job to vet actix-web for you, nor did it become his job when the library became popular, nor does invoking "security" change…

I've worked with Rust only rarely, and never built anything real from scratch with it myself, so I'm curious: what tools are available to assess the safety of dependencies? I agree with you in principle that "you are responsible for your dependencies", but how would you go about doing that for a large complex dependency like this?

Re: A Sad Day for Rust

#449

Post by rckoepke » Fri, Jan 17, 2020, 5:27 PM UTC

cycloptic wrote: post #422

rckoepke wrote: post #392

Earlier quoted context omitted.

> it's not a maintainer's responsibility to follow best-practices, respond to feedback/PRs, or respond in any coherent way to anything asked of them. I mean, I'd say that it is a maintainer's responsibility to do some of these things. If they can't, they should allow another interested&qualified person to be the maintainer instead. I understand that it's their right to abdicate these responsibilities. It's not illega…

Not everyone who uploads an open source project to some random cloud hosting service (i.e. Github) is qualified or wants to be a maintainer. Remember that being a maintainer is equivalent to project management. A lot of people publishing open source code don't seem to care about this and just want to write interesting programs. And that's fine. I personally have sent patches to lots of people who just never responded…

No, no, no - none of this is about legality. Just sometimes people bring it up as a framework for determining responsibilities, so I addressed it ahead of time. I don't think (legal requirements) == (responsibilities). The sets may have some overlap but clearly they are not identical.

Instead, I am just saying that if I upload a "cool tool" to github, and I notice that it has become super popular, and I don't have time/interest/inclination to maintain it --- I would personally feel a RESPONSIBILITY, and probably social obligation (not a legal obligation) to either put a note saying "this is not actively maintained, please find an up-to-date fork. user/cooltool seems to have community support but I can't personally endorse it." or simply make some other people additional/replacement maintainers for the project which I'm not interested in maintaining anymore.

Re: A Sad Day for Rust

#450

Post by virtue3 » Fri, Jan 17, 2020, 5:27 PM UTC

NewsAware wrote: post #361

aprdm wrote: post #337

Earlier quoted context omitted.

Where does it say he has to accept patches ? Couldn't they simply fork it instead of acting like entitled kids ?

Well, from my perspective it seems common practice in most open source projects which are hosted on GH that maintainers at least consider PRs and typically only reject if the PR is flawed, incomplete or somehow adds feature creep. Of course any maintainer is free to handle it differently, but if going against usual expectations, it would be benefitial for all involved to note reluctance to PRs prominently to the Read…

It takes time to validate a PR, to test it, to verify it. He is not being paid for his time, he does not owe -anyone- his time.

If you don't like the way a project is being run, fork it and own it yourself.

I know that's harsh, and not idealistic, but it's the way people should really think about this. People take FOSS for granted, CONSTANTLY. And maintainers even more so.