On Monday, 25 January 2016 at 22:12:06 UTC, Andrew Edwards wrote:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu
wrote:
On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:
I don't think we should read *too* much into the words.
Yeah, it's interesting. I recall thinking as I was drafting
the document: "One word... ONE word that doesn't sit well and
it will be all about that word." And now here we are. It's
like those presidential or Fed chairman press conferences...
:o).
I changed http://wiki.dlang.org/Vision/2016H1.
Andrei
The bikeshed is now translucent... However, the community still
lacks focus/direction. Pick a destination, establish To-dos and
Milestones, empower the community to make it happen, then
supervise to ensure everyone stays on task.
State the priority or at a least list of priorities. Everything
under the sun cannot be THE priority.
e.g.
1. Improve Module System
-- To-dos
-- Milestones
2. Improve Memory Management
2.1 Garbage Collector
-- To-dos
-- Milestones
2.2 Manual Memory Management
-- To-dos
-- Milestones
3. Tools
3.1 Adapt dfmt
-- To-dos
-- Milestones
3.1 Adapt dfix
-- To-dos
-- Milestones
I've been asking for this list for sometime now. It is actually
what I wanted from the Vision document, but that ended up too
broad and vague. I've since repeatedly pointed out that it
should be more specific, more like a roadmap, as you lay out.
After stating the priority, identify the most capable resources
to head each initiative, empower them with a bit of autonomy
and encourage the larger community to organize in support of
these initiatives.
These people will tend to be self-selected, but they could always
be given some leeway in a named role.
Finally, supervise!!!
I doubt this would ever happen: Walter and Andrei are not
managers, and I doubt OSS contributors would want it. The best
one can do is define a roadmap and hope it's heeded.
I wanted to say this earlier but forgot: what D is trying to do
is impossible. You cannot have a successful OSS project that has
a high technical standard and no commercial backing. OSS
projects tend to be more like ruby and rails, where most anything
goes. Projects with a high technical standard have to be more
selective, so they go against the OSS grain. When that happens
in OSS, it's usually because of commercial backing.
It is amazing that D has gotten so far as an OSS project without
commercial backing, a credit to the engineering sense of Walter
and the core team. But I don't think you can organize your way
around that fundamental obstacle.
Of course, I'd likely have said OSS being so widespread would be
impossible a couple decades ago, but OSS has certainly garnered a
niche, once it was coupled with commercial models.
