Subject: Re: [boost] [peer review queue tardiness] [was Cleaning out the Boost review queue] Review Queue member requirements
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-04-03 09:07:55
On 3 Apr 2015 at 13:14, Vladimir Prus wrote:
> > I also feel surprise that no corporate sponsor hasn't sponsored such
> > tooling yet, and that makes me suspicious if they are as easy to
> > implement as I think.
>
> I'm not really surprised about that part - selling tools is generally
> hard, especially targeting less tangible aspects like quality, especially
> addressing third-party open-source products. It's not like corporations
> have budgets specifically for helping open-source projects they use.
You hugely speak the truth here. For some odd reason, tooling is seen
as a cost overhead instead of a productivity investment. Expenditure
is unwisely allocated as a result, and I've seen that attitude at
almost every corporate employer I've ever worked for. One of the few
orgs to really understand that tooling is a productivity investment
not cost overhead is Microsoft, and you can see that in their
excellent Visual Studio which is effectively given away for free
nowadays, but it pays off hugely in saving the time of anyone using
it (i.e. the rest of the org, everyone in the ecosystem).
We're guilty of it here at Boost too though. The SC has been clear on
not being willing to fund paid work on Boost, though they kindly made
an exception for GSoC student extensions. I can see their rationale
on this - some open source orgs are really marketing, branding and
funding platforms, and as much as I think systems programming
(including C++) direly needs one of those, I can see the arguments
against funding major feature work.
However tooling I think is different. Crappy tooling is a
productivity drag on everybody, so it's a public good and therefore
needs community funding as no one person will fund it alone given the
individual benefit to cost. It would be super great if everybody
affected chipped in $5 to a fund to get a given piece of tooling
fixed, but the SC did not indicate enormous enthusiasm for what would
effectively be a bug bounty system. The big problem of course is
choosing someone to do the work for the bounty, and then others might
feel excluded, and then it might get political and aggravated and
unpleasant. Essentially it could be a lot of admin aggro for little
gain.
In short, there are no easy fixes, and it's always easier to do
nothing.
Niall
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/