Re: [boost] CMake Announcement from Boost Steering Committee

Subject: Re: [boost] CMake Announcement from Boost Steering Committee
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-07-21 11:41:06

> The SC can go ahead and implement everything themselves while all the
> people that did all the real work leave.  What a colossal example of
> arrogance and overstepping.  I agree with Vladimir Prus except that I
> wouldn't vote to reelect any of them--including those that have
> contributed to Boost.  And, no, Niall, having done some good does not
> make someone above reproach.

I have seen some enormously ignorant, petty and sanctimonious guff
spoken here during this thread, sufficiently so that it makes Reddit
look a positive bastion of enlightenment and positivity. It paints the
Boost developer community in a sorry light, very sad. But I felt it was
important for the SC to handle its own PR, so I have said nothing and
will continue to do so.

But as someone who has in the past strongly and repeatedly criticised
the steering committee for doing no steering and being generally unfit
for purpose, I now find myself morally obliged to defend it for doing
some steering finally, especially as by making decisions which are
actually controversial it is finally fit for purpose and demonstrates
the long absent vigour finally returning to this community after nearly
a decade of moribund, directionless stagnation.

There are lots of good reasons why library developers should not be a
majority on the steering committee, and hence are not:

1. Library developers see the world as a top 1% experienced elite C++
developer. They frequently, if not usually, fail to see that same world
from the perspective of the 99% of everybody else, and often are
*incapable* of seeing that same world from the perspective of the majority.

Bjarne has often said publicly that Boost's biggest design flaw is how
hard it is to get up and running with it quickly:

- Why are top layer APIs riddled with templates instead of being hidden
behind simplified convenience typedefs and non-template conventional OO
class designs instead?
- Why if most of the library is header only capable can't you just drop
in a single header file and get to work?
- Why is it acceptable for compile times to be so severely affected for
end users?

... and the list goes on (more at
http://www.stroustrup.com/bs_faq.html#boost). And how many times have I
and other end users said the same now? Yet some library developers don't
care: they want their cathedral pure and beautiful. And damn the end
users if they are too stupid or ignorant to appreciate that cathedral in
its untainted majesty.

Well, that's just ignorant and self serving elitism. We can do a lot
better, be friendlier, more welcoming, more inclusive, make things
easier rather than harder for everybody else in C++. After all C++ is
fighting for its life against the upstart systems languages, we don't
have the luxury to being mean to end users anymore. A steering committee
of non-Boost-developers stands a far better chance of seeing the bigger,
wider, long term sustainable picture than individual library developers
unwilling to look outside their own library's limited silo, and their
own limited and narrow self interests.

2. Library developers tend to love coding, else they wouldn't have
invested the many years of unpaid effort to get a library into Boost. As
a general rule, but not always, people who love coding don't much like
doing non-technical admin. It can be the case that people who don't much
like doing non-technical admin don't realise how hard it is to be even
reasonably competent at it, they think it surely must be easy to
shepherd cats because people who do it tend to currently be paid less
and have currently lower social status than they have.

What they forget however is that shepherding cats, especially when you
can't bribe them to behave with regular payments of money better known
as "a salary", is extremely hard. *Far* harder than getting a library
into Boost. And to be even remotely competent at it when you can't bribe
people with "salary" is rare.

Now Boost has been enormously fortunate to have the treasure which is
Jon Kalb and the ecosystem of people around him which makes so much of
Boost and C++ "just happen" without it being obviously made to happen.
These people don't appear here, indeed most don't even subscribe to
boost-dev because they are not library developers. But they are **just
as important** to making Boost work and function as all the library
developers and maintainers are. If they all quit, the website, mailing
list, library releases, conferences, and **all your hard work on your
library** stops happening. Moreover, **C++ itself** stops happening as a
viable long term programming language. That means that the 10,000+ hours
you've invested in your career and training becomes **worthless**. That
eventually means dumping another 10,000+ hours into something else like
Rust or Swift, but most of us aren't that young and free anymore. We're
locked into C++.

So stop dumping hate on the non-technical admin side of Boost and C++.
If you have a problem with them, it's the same as library development:
if you'd like the non-technical admin to be done differently,
**volunteer** and join the small army who do the non-technical admin.
Otherwise stop whining when they take decisions that you don't like. If
you had taken any time to be familiar with what is discussed in the
non-technical admin community, then this decision about cmake above was
obviously coming over this past year. I was part of multiple off list
discussions, and that was a small subset of the total ongoing. Indeed,
it's why I've been so sweetness and nice here on boost-dev in the past
year, I was finally seeing some movement on choosing a direction for
Boost after many years of trying to no avail. So no longer any need to
be nasty here anymore. And for the record, more controversial breaking
change is coming. So don't be surprised when it lands.

3. Boost is very fortunate and unusual amongst open source projects to
be very wealthy. They have more than enough money to employ contractors
at US market day rates to implement a complete cmake transition in weeks
if they so chose.

However they do not wish to do that if it can at all be avoided. It is
felt that a spontaneously designed and implemented cmake solution by the
community for the community would be much better in terms of coming up
with the right design, and generating buy in amongst a critical mass.

Now I'll freely admit as a veteran contributor to the Boost git
migration that I find that unrealistically naive. I think it can only
work if you drop half the Boost libraries with more complex build needs
from the distro, and as much as dropping half the libraries is something
I personally want too, the problem is that those halves are not the same
halves. I want the undermaintained half of libraries dropped, not the
well maintained libraries with complex build needs.

Anyway, I'm not on the SC, so I can't say what discussions have been
happening off list about that. But I can say that there have been
discussions, I have occasionally been looped in off list on specific
points only.

If the SC were all library developers, I think there would be a
temptation to spend some of that cash pile on library development - I
certainly would, but then I'm a library developer. I may not personally
agree with the rationale to never spend money on development as has
historically been held by the SC, but I do understand its logic: the
money is there to lubricate and facilitate, not to drive development or
admin itself. The current rough balance of half non-technical admin and
half library developers on the Boost SC is probably therefore ideal,
despite that from boost-dev's perspective the non-technical admin
obviously contribute nothing useful.

There will no doubt be lots of angry responses to this. And I apologise
in advance to those on the SC that I promised I would not participate in
this thread. But hey, you guys been taking a beating both here and on
Reddit, and I know from off list discussions that it's gotten some of
you very down. I want you to know that despite our past differences, I
have your back. Breaking change is always unpopular, that's why it's so
vital to do it regularly.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/