On Sep 3, 2012 2:58 PM, "steve@parisgroup.net" <steve@parisgroup.net> 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