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/