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.
