OT: 'conduct unbecoming of a hacker'

[Ola Fosheim Grøstad via Digitalmars-d]

On Thursday, 11 February 2016 at 09:51:16 UTC, Joakim wrote:
> 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.

Yes, it does take decades to create complicated productivity apps.

The only open source productivity app I use that isn't GPL is 
Open Office (IIRC), but it uses LGPL components, and is more 
corporate than community...

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

Android is based on Linux... but this is not how I remember it. 
Bill Gates went public with statements against FOSS way before 
Android appeared. He was clearly frustrated by how Linux made 
inroads in the server market.

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

I've repeatedly stated that libraries, phobos inclusive, are 
inconsequential.

What matters is the language, compiler and runtime.

Libraries are luxury items.

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

No. A standards committee is a collection of representatives that 
are trying to balance out different conflicting agendas.

If you build at team you are better off establishing consensus. 
So step one is to attract people with the same agenda. So if you 
want to fork you should try to build consensus within a faction 
and then branch off. If only 1 or 2 people create a fork it will 
most likely go nowhere.

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

Yes, I've given that some thought. But for it to pay off you need 
a refactor high quality code documented code base. If a 1-2 
person team is to serve customers you cannot waste hours on poor 
infrastructure.

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

One project got pretty far, but then it went dead because their 
life situation changed as far as I can tell.

Another one is alive, but is too close to C++, but not close 
enough:

http://loci-lang.org/

I think Loci looks quite ok, but it might be too influenced by 
personal taste. I think the same applies to many languages, even 
Rust, Go and D. Too opinionated, by not entirely well founded 
priorities.


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

Yep, that's true. I don't need any other languages than C++, 
TypeScript and Python. But what I need is not the same as what I 
want!


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

Well, I think it matters that people can sit around a table and 
talk. And one can probably find solutions for doing cooperative 
work in a better way with the high bandwidths we have on the 
Internet today. But building a team with a shared vision and the 
right knowledge/attitude is not so easy either.

Doing innovative things as a collective is very challenging. I 
think it takes much higher communication/people skills than is 
commonly found in these kind of projects.

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

Which features are you thinking of? I think D has rushed to 
implement proposed C++ features... (It can take a decade for 
things to make it into C++)


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

So, what is the process? Where is the quality assurance?

They have to do managment if they want to lead. Architects do 
manage the process. They don't lay down bricks. That's how great 
buildings become... great.

And no, a programming language cannot be a "bazaar" (that's Php 
and Perl).


> But I don't think consensus is useful, what matters is making 
> the right technical decisions.

It matters if you don't want to go solo.

> Consensus is for getting everybody doing the same thing, which 
> is not the road to technical quality.

Consensus is for building a shared vision of what the future will 
look like so that people thing the project is worth backing and 
will go somewhere. Then you can have more independent processes 
on the details.

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

Yes. But it could be simple. Like.

1. full feature freeze
2. heavy refactoring
3. full documentation of module x, y and z.

+ some details on goals and planning

> anyway?  It then becomes one of those corporate mission 
> statements, which are notable only for stating the bland and 
> the obvious.

Yes, bland missions statements have little value by themselves, 
although for very big and fractured groups they can get some 
sense of a "we", although I think often the process is more 
important, i.e. the social communication between groups can be 
more important than the resulting mission statement.