On Fri, Sep 11, 2020 at 11:52:02PM +0200, Paul Boddie wrote: > Social factors: you will see plenty of inertia or what people used to call > "stop energy" in the mailing lists. Just review the previous messages on this > list or look at recent messages on bug-hurd for examples. One gets the > impression that unless someone is either a top-level operating system > architect and/or willing to burn themselves out fixing up huge amounts of > existing code or writing new code in precisely the way envisaged by others > who > nevertheless aren't going to be writing any themselves, then new > contributions > are not really welcome.
Well it doesn't need to be "precisely" the way those who aren't active at the time like me imagine it. Good surprises are welcome too, but those are rare. You seem to imply one doesn't need to be "a top-level operating system and/or willing to burn themselves out fixing up huge amounts of existing code" to work on something like the Hurd. While I'm not personally requiring "top-level" anything, I very, very, very strongly believe that a project that combines concurrency, virtual memory, and distribution, requires developers who care deeply about both the big picture and small details, and to me, that's usually what makes a top-level developer. Besides, considering how badly designed some critical parts of the code are, yes, it would require a lot of work to get that fixed. So yes, we need people with both great technical skills and very hard-working. That too is rare. > I recently read an article about Linux kernel development where someone > actually wrote that if something or other made kernel development easier or > more accessible then it would be attracting the "wrong kind" of people. Well, > that would seem to be the view of some people in the Hurd development > community, too, judging from recently expressed sentiments. That's absolutely not correct about the Hurd, however. I guess you're referring to me saying "I don't want to work with people who give up because it takes them more than a few seconds to find information". Note that I'm absolutely not implying to artificially make finding things hard. They just are, and I'm not aware of any tool that grabs a big, old, fragmented code base like that of the Hurd, and makes it easy and quick to understand. Serious projects need the right kind of lazy people, those who try to do things well from the start to avoid wasting time fixing bugs and rewriting large code blocks, instead of the wrong kind of lazy people, who just give up quickly and are negligent. > Of course, many other people in the wider world realise that successful > projects require many different types of contributors in order to actually be > successful, and judging by the increasing stagnation of what was a fairly > well-resourced and well-publicised project, I think we can guess whose > viewpoint is the more realistic of the two. Again, not correct. I said I didn't want "someone not fit for the job" and you're intepreting I don't want "different types of contributors". I also would like to know when the Hurd was well-resourced these last twenty years. Overall, you seem to claim that the Hurd would be better off with many mediocre developers than very few excellent ones. In addition, your argument makes a vague comparison between the Hurd, which is at its core an amibitious and technically difficult project, and other "successful projects" which are statistically far from being that difficult, not to mention the survival bias. Well I simply disagree, I'd rather see the Hurd stagnate in a form that gives it a chance to take off again than evolve into a hopeless abomination. Productivity can be very low, even negative, i.e. doing more work fixing contributions than the work put in the contributions themselves. Fine-grained multithreading and parallelism/distribution in general are particularly prone to create such situations. In the end, those statements are morally charged misinformation, which is simply annoying. -- Richard Braun
