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