Re: [boost] Draft copy - Call for Submissions - CMake for Boost

Subject: Re: [boost] Draft copy - Call for Submissions - CMake for Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-19 17:46:34

On 10/19/18 4:45 AM, Andrey Semashev via Boost wrote:

> For the sake of mailing list and similar conversations, including the 
> review, real names probably don't matter that much. Although, frankly, 
> on this list there aren't many regular participants who use an alias.

Boost traditionally has encouraged participants to use real names. I 
think this is a good thing and I think keeps discussions from going down 
hill - on other forums as well as boost.  I was suggesting that this 
might be an exception to our normal policy.

> But there are contexts where real names are required or simply 
> appropriate. For example, in copyright notices in the source code or 
> documentation. Or IRL communication, should one happen e.g. in C++Now or 
> somewhere else.

Of course

> There is also an awkward moment when you reveal the author's name, who 
> was previously known by an alias, at which point you only cause 
> confusion. And probably either you or the author has to prove his 
> authentity.

Hmm - I'm not seeing this - but maybe.
> 

>> My idea was that making it more attractive for potential submitters, 
>> we might draw more submissions than we otherwise might and hence end 
>> up with a better one.
> 
> That's part of my argument - you're trying to attract submitters that 
> would normally not want to make the submission and potentially don't 
> want to be part of Boost. At least, that's what the document draft says. 
> This is bad for Boost and the potential submitters.

So one who is uncomfortable about revealing his true identity might have 
difficulties when his identity is revealed in dealing with the reality 
that is boost.   I can certainly see your point here.

As I've said - it's an idea and I'm glad it's being discussed.

For some time I've been concerned about the future of Boost as an 
organization.  This is one idea - I'm curious about others.  Here ate 
the concerns I have:

a) With C++11, the standards committee accepted a large portion of Boost 
into the standard.  This left it unclear as to what the future value of 
Boost to C++ might be.

b) The standards committee has ramped up it's efforts to include library 
proposals directly into the standard - thus side stepping the 
traditional requirement of "standardizing established practice".  So 
this has left Boost outside of the development of the C++.  A example of 
this has been the Ranges library which as been designed and developed 
totally within confines of the C++ standards committee.  This 
effectively marginalizes Boost.

c) This effort by the committee is basically failing.  It's creating the 
possibility that C++ will evolve into an ever larger and 
incomprehensible bag of features than it already is.  It puts C++ on a 
slow train to oblivion. This is not usual with successful projects which 
expand their scope - as the committee has done.  It's especially common 
for organizations run as a committee.  Think large corporations: Kodak, 
Sears, All government organization, universities - etc.

All one has to do to see this is look at the papers list for the san 
diego meeting.  Also look at P0977r0.  Consider that it take the 
committee 10 years for a proposal to evolve into something that can be 
delivered to users.

Of course the C++ committee won't address the situation.  Committees 
don't do that. Oh - now they want to expand scope again to include 
tooling.  Wake up and smell the coffee people.

d) Hence Boost has a reason to continue and exist. But Boost is also a 
committee - albeit a better designed one. It has to evolve as well. I 
think it can evolve if we continue to work on the stuff we've been 
successful at while at the same time experimenting with new ideas.

This is the motivation behind this proposal and a number of ideas 
contained therein.

Robert Ramey