OT: 'conduct unbecoming of a hacker'

Wed Feb 10 23:32:00 PST 2016

On Thursday, 11 February 2016 at 06:20:33 UTC, Joakim wrote:
> Eh, there were always the BSDs and essentially nobody runs GNU 
> code today.

Uhm... Many do. And beyond GNU, the GPL/LGPL are the most common 
licenses in community driven open source productivity 
applications: Gimp, Inkscape, Blender, Audacity...

> My point is that people see the success of open source and his 
> early role as a vocal proponent and assume he was "critical," 
> when the truth is more complicated, as his extreme formulation 
> of completely "free software" has not done that well.

It has not done well with corporations, but it has done very well 
with open source end-user software! Even projects that are not 
GPL tend to use LGPL code.

Yet, Linux did manage to scare the juggernauts, so now even 
Microsoft is starting to publish under liberal licenses (first 
very restrictive, now very liberal).

> This is why you should generally only work on something you 
> actually need, which is a great discipline.  Even if it's 
> rejected, you can code it up and use it yourself, though that's 
> not always possible with certain language changes and DIPs.

Well, yes. Unless you are designing a standard library. The 
original open source projects were mostly about recreating 
existing designs, but with a open source license. So the missing 
features were obvious. In the case of GNU (Unix), it is a cluster 
of individual small programs. So if people was unhappy they wrote 
a new version from scratch. And the most popular ones survived.

Creative designs that went open source tended to be research 
projects... so you had a clear vision (and people who were 
experts in their field leading the design).

So, the linked rant is pretty clueless IMO. You need to form 
consensus in order to gain focus. If you don't have focus you'll 
never end up with something coherent. If the author believed in 
what he wrote, then why did he write it? He obviously wrote it 
because he believe that communication  can lead to change. And 
thereby he undermines his own argument...

What brought original FOSS projects focus was the fact that they 
were not implementing original designs. And there has been LOTS 
of advocacy and arguments on usenet about every creek and cranny 
in software... since way before the Internet existed.

So, it was an entertaining rant... and nothing more.

> For example, I asked about ARM and mobile support for D in 
> 2011, noting that mobile was starting to take off and that 
> people had been asking for ARM support periodically for years 
> even prior to that.  I was told it was one of many priorities, 
> but nobody knew when it'd be worked on.

Yes, and this is all good, but it is not a language issue. It 
fits well with what makes contributing to GNU/Unix easy. You can 
write an isolated piece.

> While this is not generalizable for all D PRs, ie nobody wants 
> to maintain a fork of certain language features, it is for

Several people have created their own languages because they have 
given up on the D development process...

> for dmd.  Caring enough about a change to code it yourself is a 
> good test for whether it is worth doing, which is one point the 
> original post alludes to.

Writing code without a fork, when you know it will be rejected, 
is pointless.

Spending days or weeks on a DIP, in order to have it dismissed by 
a "nice technical DIP, but does not fit with our vision", is very 
wasteful.

So people create their own languages instead, but without 
building consensus, meaning they end up in an incomplete state or 
being to close to D, having a different set of issues. Which is a 
key aspect of D's problem too, it is too close to C++ to not be 
compared to it. So fixing some issues and introducing others 
isn't good enough for adoption.

Building consensus is very important. Just take a look at 
politics. Communicating a clear vision and a believable path to 
implementation is essential. And listening. Good leaders are 
always very good at listening, IMO.