What is the D plan's to become a used language?

[Joakim via Digitalmars-d]

On Friday, 19 December 2014 at 17:14:57 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 19 December 2014 at 16:59:54 UTC, Tobias Pankrath 
> wrote:
>> How would that improve the development process? Which problems 
>> that we currently face does that solve and why? I'm not trying 
>> to troll here.
>
> 1. You can hit a stable release for a particular application 
> area one by one: batch programming, server programming, 
> realtime programming. That could increase commercial uptake 
> because you hit the first stable (supported) release earlier.
>
> 2. You can defer decisions so that they happen in the right 
> order, and still let people work on a solution 3 releases ahead 
> know when their work will be evaluated.
>
> 3. You can assign different people with different expertise to 
> coordinate a specific development area (like GC improvments).
>
> 4. You can make sure that design-problems that are interlinked 
> are treated at the same time so you don't have to go "oh no, 
> that won't work, because we added Y in another release".
>
> 5. You can break down the problems into smaller problems and 
> line up milestones and dependencies.
>
> 6. You can defer all discussions that are truly breaking to a 
> working-group focusing on a breaking 3.0 release.

Some decent suggestions for a company that has a certain game 
plan, but mostly useless for an open source project where every 
contributor has their own priorities.  The core team can only 
work on what they think is important and evaluate whether they 
want others' features or the quality of their pulls, whenever 
those are provided.  Think bazaar, not cathedral.

Now, you're right that the core team can do a better job of 
laying out their current priorities and of having an actual 
roadmap of where they'd like the project to go, but they can't 
really do anything to enforce this herd of cats to listen to them.