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.
