OT: 'conduct unbecoming of a hacker'

[Joakim via Digitalmars-d]

On Thursday, 11 February 2016 at 07:32:00 UTC, Ola Fosheim 
Grøstad wrote:
> 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...

All of which are decades-old projects from the heyday of the GPL, 
when many mistakenly attributed linux's success to the GPL and 
copied its license blindly.  Almost nobody starts new projects 
with the GPL today, and it seems they've also given up on such 
OSS productivity apps.

>> 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.

Define "very well." :) Because I've listed multiple 
permissively-licensed projects that are a couple orders of 
magnitude more widely used, and I see almost no GPL software even 
close.  It's basically just the linux kernel and that's it, and 
that only because it was piled high with permissively-licensed 
and even closed software on top, with Android.

> 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).

It did nothing of the sort, as GNU/linux basically went nowhere 
and MS didn't care.  It is only once permissively-licensed 
software like Android and parts of iOS hit billions of devices 
that MS started doing so, under permissive licenses like those 
projects, not the GPL.

>> 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.

Anything you want to add to a standard library can easily be 
maintained in a private fork or put up on dub, as you've 
suggested doing to all of phobos.  So even if you don't get a 
change into the standard library, there's nothing stopping you 
from using it or distributing it, so this comment seems pointless.

> 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...

I agree with everything till you start espousing consensus.  If 
anything, consensus often leads to the most incoherent designs, 
ie design by committee.

> 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.

It had some good points, but was inconsistent.  Perhaps one 
reason OSS projects have become less willing to take his patches 
is that they've become much more widely used, where if your 
project ships on Android, it will be used by a billion and a half 
people.  Given that these projects are still way understaffed- 
look at OpenSSL and its Heartbleed bug- it's understandable that 
some would be conservative.  Of course, it's possible that the 
projects he talked to had almost no users, so it all depends on 
the scale of the project, as I said before.

>> 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.

Even with language issues, there is potential for deviation.  For 
example, if you think there might be commercial users for that 
feature, you could sell them a slightly forked version of dmd 
with your feature.  It's what the zapcc devs did with clang:

https://www.phoronix.com/scan.php?page=news_item&px=New-Zapcc-Clang-Benchmarks

If it works out well enough, maybe you could integrate it back 
upstream eventually.

>> 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...

And how far have they gotten?  Entire forks don't get very far, 
but a tracking branch with a few additional features can do just 
fine.

>> 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.

Then perhaps you didn't really need that code, if you wouldn't 
have gotten much use out of it on your own.  Yes, I've admitted 
that maintaining some language features is too painful or 
different to maintain in a private branch, but many can.

> 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.

I agree that it would be better to nip that in the bud where 
possible or better explain why the DIP doesn't fit, but many 
times such rejection is an inevitable byproduct of maintaining a 
high technical standard.

Now, maybe it's impossible to maintain a high technical standard 
with a community-driven OSS project and you need a business model 
to be able to afford such exploration and possible waste of time. 
That may be a fundamental tension between technical quality and 
the OSS development model that cannot be resolved.  But I see no 
way around such rejection if you want to maintain a high level of 
quality.

> 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.

One of the reasons it's close is that new versions of C++ are 
copying D. :) I don't blame them for doing so or think there's 
anything wrong with it, but there are still enough problems with 
C++ that I don't think it'll be enough.

> 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.

Yes, politics, look at how much the politicians get done! ;) I 
think we all know and Walter and Andrei have said that they're 
not managers.

But I don't think consensus is useful, what matters is making the 
right technical decisions.  Sometimes that comes from long 
technical debate where everybody shoots holes in everybody else's 
ideas and eventually somebody decides to implement the least 
bullet-ridden idea.  Sometimes it comes from one person going 
down a path only they see the end to.

Consensus is for getting everybody doing the same thing, which is 
not the road to technical quality.  Linus has talked about the 
"wasteful" OSS approach, which he compares to evolution:

http://bobweigel.net/projects/index.php?title=Weigel/Notes#Linus_on_Development

Everything else about vision and listening, sure, but in an OSS 
project everybody is free to ignore that vision.  It's one reason 
why I wish the official vision statement was much more specific 
and daring, because no matter what, we're free to ignore it, so 
there's no risk.

At least you laid out a specific, original vision, and we can see 
if we want to follow it.  But if you make bland, shapeless 
statements like "Improve quality," weren't we trying to do that 
anyway?  It then becomes one of those corporate mission 
statements, which are notable only for stating the bland and the 
obvious.