Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?

Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?
From: Neil Groves (neil_at_[hidden])
Date: 2012-09-05 05:34:25

On Sep 3, 2012 2:58 PM, "steve_at_[hidden]" <steve_at_[hidden]> wrote:
>
> Greetings,
>

>
>
> Right now I'm working for a company that worries a lot about negative
exposure to Open Source software issues such as questions that might arise
about authorship, copyright or even patent issues.  The company does allow
the use of Open Source software, but it requires that each piece of code
that is brought in first be justified and vetted.  Unfortunately, I'm
finding this to be a nearly impossible task when I look at the amount of
code that must be compiled to use the Boost modules I'm interested in.
>
>

Why would open source be more likely to infringe a patent than your own
solution? It is less likely in fact since the public availability of code
can be used to demonstrate prior art.

Incorporating third party software into your own QA process is often very
sensible.

>
> I've done a study and written some tools, to determine just how many
Boost header files must be included to use some of the Boost modules.  The
numbers are staggering:
>
>
>
>    Any: 79
>
>    FileSystem: 276
>
>    Smart Ptr: 382
>
>    String Algo: 180
>
>
>

I am not staggered. Additionally the number of files has to be one of the
most useless software metrics in the known multiverse!

> I went on and did a tally of which modules these header files came from.
 Here are the counts for how many other Boost modules each of these modules
depends upon:
>
>
>
>    Any: 8
>
>    FileSystem: 13
>
>    SmartPtr: 8
>
>    String Algo: 15
>
>
>
> Given these numbers, I think I have to abandon any thoughts of using
Boost within my current company.  There's no way I'm going to get approval
to bring so much code into our work just to get a SmartPtr or FIleSystem
library.  This is unfortunate, because due to Boost's existence there
doesn't seem to be much work going on out there to offer lighter weight
alternatives.
>
>
>
> I'm writing this request in the hopes that there's something I'm missing
here, and that someone can point out my folly.  Is there a way to utilize
any of these Boost modules in such a way that they do not require the
inclusion of so much code?  If not, does anyone have any suggestions as to
how to make this fly with my boss?  Has this issue come up before and been
considered by the Boost designers?  I find the issue baffling.
>

The issue simply isnt a development priority. We prefer to emphasise good
interfaces to correct code. The internal header file coupling has a
potential to increase your build time. Why else do you care (aside from
justifying an arbitrary procedure)?

If you have compile time issues please bring these up concretely and with
measurements.

>
>
> TIA for any help or insight anyone can provide.
>
>

My recommendation would be to look for another job!

I think all the Boost devs would like to improve modularisation, and
efforts are already underway.

Frankly increasing the number of supported deployable configurations is
unlikely to improve external quality factors. It is likely to be better to
take the better tested ensemble of libraries.

Test and use what you like and leave what you dont.

I may be on my own here, but my suspicion would be that dogmatic
enforcement of inappropriate rules is the primary problem.

If you can't trust your developers to include the approved libraries you
probably cant trust then to make any change without supervision.

>
> Steve
>

Neil Groves