"Paul has kept the door solidly locked to others contributing to HN"
Does he? If you send a bug fix or feature patch to the HN arc codebase, he tosses it without looking at it? Or does he look at it and then take a decision whether to include it or not? I would imagine the latter (please correct me if I am wrong).
That he refuses to consider some suggestions, no matter how much sense it may make to the person making the suggestion (or even bystanders) is the exact same behaviour that every open source project's BDFL exhibits. I think you exaggerate with the "door solidly locked to other s contributing". If you send in a bug fix patch for example, I am sure he'd incorporate it asap.
Now the complaint reduces to "but PG refused to consider this feature though I (and many others) think it is a must have"
The traditional answer to "but the BDFL refuses to incorporate my suggestions which were liked by all the users I spoke to" is "then fork the code, and/or build something better".
My view, fwiw, is that we (users of HN) have the right to request features and present a logical case and PG (as the chief programmer/owner/BDFL etc of HN) can accept or refuse those requests for any reason whatsoever. If he explains the rationale that is a bonus, but he doesn't really need to. It is his project.
If he refuses to incorporate our fixes/suggestions, we (the hacker users of HN) can either go along with his decision xor fork the codebase (or start a new project from scratch using our preferred tools) and build something better (and I know a couple of HNers who are trying exactly that).
Comments
"Paul has kept the door solidly locked to others contributing to HN"
Does he? If you send a bug fix or feature patch to the HN arc codebase, he tosses it without looking at it? Or does he look at it and then take a decision whether to include it or not? I would imagine the latter (please correct me if I am wrong).
That he refuses to consider some suggestions, no matter how much sense it may make to the person making the suggestion (or even bystanders) is the exact same behaviour that every open source project's BDFL exhibits. I think you exaggerate with the "door solidly locked to other s contributing". If you send in a bug fix patch for example, I am sure he'd incorporate it asap.
Now the complaint reduces to "but PG refused to consider this feature though I (and many others) think it is a must have"
The traditional answer to "but the BDFL refuses to incorporate my suggestions which were liked by all the users I spoke to" is "then fork the code, and/or build something better".
My view, fwiw, is that we (users of HN) have the right to request features and present a logical case and PG (as the chief programmer/owner/BDFL etc of HN) can accept or refuse those requests for any reason whatsoever. If he explains the rationale that is a bonus, but he doesn't really need to. It is his project.
If he refuses to incorporate our fixes/suggestions, we (the hacker users of HN) can either go along with his decision xor fork the codebase (or start a new project from scratch using our preferred tools) and build something better (and I know a couple of HNers who are trying exactly that).
http://news.ycombinator.com/item?id=830736
'nough said. I've been asked 'from on high' to stop this thread and others like it so I will.