http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/
(His particular suggestion about accept patches by default is not why I post this).
'
We’re all talk

Back when I joined the hacking community, it was about making things. There were mailing lists, and before them there were dead-tree magazines, and they would be full of things that people had made. And there was discussion about those things that people made.
...
Now, it has always been a critical culture. The phenomenon of the top HN comment that complains about OP is not a new phenomenon, it is older than HN and it is older than the Internet. Various people occasionally argue that we need to be “less critical” and “less abrasive” and I am sorry to be so critical and abrasive, but I think that viewpoint is dumb. Making critical remarks is how we make code better.

However that only counts if the remarks actually do make the code better. At one time, this was more true than it is today. Minimally, criticisms were sent to a person who could do something about it, not about them, to the Internet in general.

And when that person elected to do nothing in particular, the canonical reply was to write a patch yourself. And that patch was posted for discussion, and people would poke and prod at it, and see how good of a patch it was. Did it solve the problem? Did it introduce any new issues?

And if nobody was willing to write the patch, then that was the end of the discussion. A problem is not a real problem if nobody is willing to solve it.

And if you did continue to whine that nobody else would solve your problem for you, you got booted from the list. People did whine, in a sense, but it was very different. Stallman is probably the canonical example: he whines more than just about anyone, but his whining is neatly interspersed by patches, and he is probably one of the most prolific hackers of his generation. In spite of the fact that his complaints are extremely abstract–copyrights, patent law, etc.–they are at once concrete, because he has actually built the copyleft utopia he advocates for. Not blogged about how other people should build it, or gotten into flamewars about how good it might be–he built it. The GNU project is an actual project with actual software and actual users, and now we can post that to the list for discussion. Stallman wrote a patch, and today you can poke and prod at it.

This idea that people just whine and whine until they run out of breath is relatively new. One of the first times I really saw it in full force, accepted by most of the community, was with the App Store Wars in 2008. This was the time that Apple instituted app review for all iOS apps and for one reason or another this was going to End Computing As We Knew It. Blog articles were written and heated debates were had. Even pg got in on the action. But as far as I can tell, everybody complaining just eventually ran out of oxygen. There was no mass customer exodus, and there was not even a mass hacker exodus. Android did eventually rise to become a viable competitor to iOS, but it seems to me this had more to do with pricing and carrier partners than an ideological struggle; certainly the toppling of Apple’s kingdom over this issue never happened. At best, a few egregious app review problems got fixed.

There was another tempest in a teacup when Apple got serious about their 30% cut. Article after article about how now, this time, Apple must correct this injustice or face the terrible consequences of software developers rising up to demand money that is rightfully theirs. Or something. What actually happened is that Kindle removed their online store so now you had to use (the horror!) Safari to buy books, and everybody else just raised their prices 30%. The end. No uprising, no injustices corrected, nothing.

Is it my point that Apple was right and everybody was wrong? No, not really. My point is that in the 80s and 90s when the hacker community was in crisis, the response was to write a patch. Not to whine endlessly in the blogosphere. When we were threatened by Ma Bell and Microsoft (which, kids these days forget, were way way scarier than Tim Cook can even dream of being), we wrote GNU and Linux and the BSDs. And you can laugh about things like “Linux on the desktop” all you like, but these projects are all seriously impressive achievements in their own right, that fundamentally shifted the needle on the software industry. Hackers didn’t topple Microsoft, but they seriously threatened it, and they won several battles, like the battle for servers and the battle for the Internet. Hackers of today can’t threaten anyone, or win anything. We’re all talk.
...
his “bikeshedding culture” wouldn’t be so bad if you saw it only in hacker discussion spaces, like HN, because at worst you can just add them to your hosts file. However I am sorry to report that the malaise has now infected places of actually writing code, so the problem is now unavoidable.

I have been working on a project lately that requires me to rope together various FOSS projects and extend them in logical ways. And so the last few months have been a lot of this:

    Hello folks, I need [obviously useful feature]. I realize that this is a lot of work, and you’re not going to get to it any time soon, and I need it, so I’m going to do it this week myself. I plan to do the X followed by the Y followed by the Z, and then contribute that back under [your license]. Does that basically sound mergeable to you, or are there other things we should discuss?

(Un)fortunately I have decided not to name the guilty, which makes the next part of this narrative unfalsifiable. For those of you joining us from very well-run projects like git, the Linux Kernel, FireFox, WebKit, etc., it may even be hard to believe. However if you ever have the misfortune to venture into the GitHub Graveyard of projects that aren’t quite popular (and even a few that are, in a way) you will see at once the force I am wrestling with.

My email is inevitably met not with acceptance, nor with constructive discussion, but with some attempt to derail the entire enterprise. Here are some real examples, paraphrased by yours truly:

    I think it should be done some other way, even though the other way obviously doesn’t work for you and so far nobody has ever been found who is willing to implement it that way
    I don’t want to solve this problem without also solving [unrelated problem X], your proposal doesn’t address [unrelated problem X], therefore I am inclined to reject it
    I don’t know you and there might be a bug in your patch. This patch is too important to leave to somebody new. At the same time it is not important enough for any of the core committers to get to it.
    Defend this proposal. You’re telling me you “need” encryption in an internet communications library, or you “need” unicode support in an object storage library. I don’t believe you. We’ve gotten along just fine for N months without it, and we’ll get along for another 2N months just fine thanks.
    Look, we’ve already implemented [sort-of related feature] even though it’s buggy and doesn’t cover your usecase. That decision was complicated and people were arguing about it for years and I really don’t want to go through that jungle again. If you wanted to do it this way you should have spoken up two years ago.

Common objections to patches on mailing lists

]11 Common objections to patches on mailing lists

In some cases I have made this proposal to my first-choice project, gotten one of the numbered responses, then went to the second and third-choice projects only to get a different rejection at each one. I track most of these in a spreadsheet, and many of them get in long flamewars that run on for months after I’ve unsubscribed, forked, and shipped the solution I originally proposed. Most of those flamewars come to nothing, but a few of them even end up implementing an equivalent solution to the one I proposed, all that time later. Exactly one project in my dataset ever reached a decision that actually improved on my proposed solution, and so far that decision was made in theory only–a separate flamewar erupted between the spec writers and the implementers, and that flamewar continues to this day. Meanwhile my code shipped in 2012.

Is my point that I am the best hacker, mwahahaha? No. These are largely pretty easy patches that most software developers could write in a few days. I do not claim any special talent in writing them. I simply claim that while everybody else was arguing, I was the one who did write them. And without exception, every single argument over one of these patches caused a delay and produced no benefit, at best. I am sorry to report the facts today are that flamewars, not patches, are king.
...
Who cares? Let people argue if they think it’s fun

Well, let me be clear: I am in favor of recreational arguing. Just read this blog; that is an exercise in the discipline. 2.

However, there are some limits. It’s all fun and games until somebody loses an eye. One problem is that when all the hacker spaces are infected with patchless argumentation, we discourage all the up-and-coming hackers who do, actually, write patches. The Rachels of the world are confused: is this what programming is about? It’s about winning the mailing list thread? We also attract people who are good at arguing, instead of people who are good at patches. Those are mistakes, and probably enormous ones, but the effect is hard to prove.


...
Hacking should be about making things. And yet a great many of our institutions are set up to discourage, distract, destroy, and derail the making of anything. It’s time we called it what it is: conduct unbecoming of a hacker.
'

On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote:
> http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/
> (His particular suggestion about accept patches by default is not why I post this).
> '

>
> ...
> Hacking should be about making things. And yet a great many of our institutions are set up to discourage, distract, destroy, and derail the making of anything. It’s time we called it what it is: conduct unbecoming of a hacker.
> '

Great post, and very funny.

Nick

On 02/09/2016 09:11 PM, Laeeth Isharc wrote:
>
> My email is inevitably met not with acceptance, nor with constructive
> discussion, but with some attempt to derail the entire enterprise. Here
> are some real examples, paraphrased by yours truly:
>
>      I think it should be done some other way, even though the other way
> obviously doesn’t work for you and so far nobody has ever been found who
> is willing to implement it that way
>      I don’t want to solve this problem without also solving [unrelated
> problem X], your proposal doesn’t address [unrelated problem X],
> therefore I am inclined to reject it
>      I don’t know you and there might be a bug in your patch. This patch
> is too important to leave to somebody new. At the same time it is not
> important enough for any of the core committers to get to it.
>      Defend this proposal. You’re telling me you “need” encryption in an
> internet communications library, or you “need” unicode support in an
> object storage library. I don’t believe you. We’ve gotten along just
> fine for N months without it, and we’ll get along for another 2N months
> just fine thanks.
>      Look, we’ve already implemented [sort-of related feature] even
> though it’s buggy and doesn’t cover your usecase. That decision was
> complicated and people were arguing about it for years and I really
> don’t want to go through that jungle again. If you wanted to do it this
> way you should have spoken up two years ago.
>

Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating.

On Wed, Feb 10, 2016 at 12:17:40PM -0500, Nick Sabalausky via Digitalmars-d wrote:
> On 02/09/2016 09:11 PM, Laeeth Isharc wrote:
> >
> >My email is inevitably met not with acceptance, nor with constructive discussion, but with some attempt to derail the entire enterprise. Here are some real examples, paraphrased by yours truly:
> >
> >     I think it should be done some other way, even though the other
> >way obviously doesn’t work for you and so far nobody has ever been found who is willing to implement it that way
> >     I don’t want to solve this problem without also solving
> >[unrelated problem X], your proposal doesn’t address [unrelated problem X], therefore I am inclined to reject it
> >     I don’t know you and there might be a bug in your patch. This
> >patch is too important to leave to somebody new. At the same time it is not important enough for any of the core committers to get to it.
> >     Defend this proposal. You’re telling me you “need” encryption in
> >an internet communications library, or you “need” unicode support in an object storage library. I don’t believe you. We’ve gotten along just fine for N months without it, and we’ll get along for another 2N months just fine thanks.
> >     Look, we’ve already implemented [sort-of related feature] even
> >though it’s buggy and doesn’t cover your usecase. That decision was complicated and people were arguing about it for years and I really don’t want to go through that jungle again. If you wanted to do it this way you should have spoken up two years ago.
> >
> 
> Unfortunately, that sounds very similar to experiences I've had here in D-land :( Gets very frustrating.

Have to agree with you there. :-(

While, on the whole, my experience of D has been very pleasant, and I will probably stick to it for the long term, there *are* some rough edges that, arguably, should have been ironed out by now. But every time the topic comes up people get defensive and then the interminable forum threads ensue, and at the end nothing gets done because everyone is spent from all the arguments.

More and more, I've found that participating in forum threads is, in general (there *are* exceptions), inversely proportional to actually getting stuff done.  So nowadays I rather just submit a PR instead of getting entangled in the latest Great Debate. OTOH, even PR's can also get discouraging sometimes when it touches certain controversial issues, when it can get stonewalled for months on end, a great deterrent for new contributors to join in.


T

-- 
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen

On Wednesday, 10 February 2016 at 02:11:25 UTC, Laeeth Isharc wrote:
> http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/
> (His particular suggestion about accept patches by default is not why I post this).
> '
> We’re all talk
>
> [...]

Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus.

As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted.  Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D

I don't think the D community actually has these problems that much, as most of the talk is about technical issues, not whether Apple is doing this or that with their business.  The fact is that software was not as big a business back then, whereas the largest companies on the planet are built to write software nowadays, so of course people talk a lot more about how the giant software company du jour's actions affect them.

On 02/10/2016 01:09 PM, Joakim wrote:
>
> Pretty funny that he chose Stallman as his example of a guy who gets
> stuff done, whose Hurd microkernel never actually got done, :) though
> certainly ambitious, so Stallman would never have had a FOSS OS on which
> to run his GNU tools if it weren't for Linus.
>

[Unimportant theorizing ahead...]

I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd.

On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote:
> Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus.

Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix.

But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL.

Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software.

> As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted.  Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D

Well, both Emacs and GCC have had their forks... so. Yes.

On 02/09/2016 09:11 PM, Laeeth Isharc wrote:
> http://sealedabstract.com/rants/conduct-unbecoming-of-a-hacker/
> (His particular suggestion about accept patches by default is not why I
> post this).


Just read the rest of the article. That's a REALLY good article. Especially these bits:

===============================

"Consider the following outcomes, which happen with some regularity:
* [...]
* Objections that the problem should be solved another way, but that are accompanied without any volunteers to do it that way. A patch in the hand is better than two in the bush. If somebody does end up doing it the “right” way someday, git revert is only 10 keystrokes. The fact that someday a better patch might appear is not an argument against merging an adequate patch right now.

* Bare assertions that there is no need for the feature, when the fact that somebody wrote a patch should be primae facie evidence that the feature was needed"

-------------------

"Really, what I’m asking is this: Which is more convincing? Concrete computer code authored by someone with first-hand knowledge of the defect? Or the bare assertion that something is wrong with it? I mean, either one might be correct. But the first is better supported."

==============================

Really like: "A patch in the hand is better than two in the bush."

On Wednesday, 10 February 2016 at 18:31:22 UTC, Nick Sabalausky wrote:
> On 02/10/2016 01:09 PM, Joakim wrote:
>>
>> Pretty funny that he chose Stallman as his example of a guy who gets
>> stuff done, whose Hurd microkernel never actually got done, :) though
>> certainly ambitious, so Stallman would never have had a FOSS OS on which
>> to run his GNU tools if it weren't for Linus.
>>
>
> [Unimportant theorizing ahead...]
>
> I wouldn't say that's necessarily true: It could be argued the existence and proliferation of the Linux kernel reduced the priority of his Hurd work, even if only to a subconscious extent. If it hadn't been for the Linux kernel, maybe there would have been more drive (and more contributors) to Hurd.

I've read that the bigger issue was that they couldn't quite get Hurd working on '90s hardware, and the simpler linux kernel outpaced it, ie I doubt linux displaced Hurd contribution as they're different approaches.

On Wednesday, 10 February 2016 at 19:07:27 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 10 February 2016 at 18:09:57 UTC, Joakim wrote:
>> Pretty funny that he chose Stallman as his example of a guy who gets stuff done, whose Hurd microkernel never actually got done, :) though certainly ambitious, so Stallman would never have had a FOSS OS on which to run his GNU tools if it weren't for Linus.
>
> Well, 386BSD was there in 1992-1994, and several other OSes, so I don't think Linux is that special. Linux did have the right timing. Amiga and other specialized hardware was becoming less attractive at that point in time, and students were getting x86 PCs with MMUs and wanted an OS that was more like Unix, but less crude than Minix.

Still means he'd have had to rely on others to provide his OS, plus BSD was under a legal cloud at the time, which is one of the reasons people say linux lapped it, and he'd probably resent it not being GPL, so it wouldn't work for him anyway.

> But I don't think Hurd is much of a Stallman coding-project. His core project is the GPL and he did created Emacs and GCC which were very important for the spread of the GPL.

I thought he was intimately involved with Hurd, but I don't follow it.

> Before GPL most academic software had very limiting "free for non-commercial educational use" clauses in their licenses. The GPL itself is much more important than any individual piece of software.

Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too.

>> As for the main point about useless bickering replacing hacking, that's probably because it was a much smaller community back then, so it consisted of only the really hard-core who wanted to _do_ something, whereas now it's expanded outside that group to the more half-hearted.  Either that or he has on the usual rose-colored glasses for the past, the usual veteran complaint, "Everything was better when I was young!" :D
>
> Well, both Emacs and GCC have had their forks... so. Yes.

Forks are a different issue, as he'd probably say that's real technical disagreement.  He's talking more about silly reasons, though I guess forks are sometimes started because of the same dismissiveness he lays out.

On Wednesday, 10 February 2016 at 19:44:50 UTC, Joakim wrote:
> Perhaps historically as a guinea pig, but its use is waning for more permissive licenses, which have been around for decades too.

Well, they had been around for things like X11, which had a commercial consortium driving the development. X11 was just a reference implementation, and members got early access to it so that they could implement it in their proprietary X11 terminals before the general public got access to it...

But as (even public) universities were pressured to earn money from their research the heads higher up insisted on anti-commercial licensing. Only when GPL gained traction could the comp. sci. people start to push for something more liberal.

IIRC the most standard licensing was educational-use, non-commercial-use or public domain back then. People had to pay for their compilers and IDEs too... quite a lot... And phone bills from using BBSes. Shareware was a much more accepted concept at that point in time too... GPL changed the world quite significantly.