Why Manually Tracking Usage of Open Source Components is Futile?

November 4, 2015 Guest Authors of WhiteSource

So the problem with manual reporting is that manual reporting depends on perfect compliance and we all know that humans are not perfect beings and we don’t always get everything right. That’s particularly true on development projects, especially when you’re trying to move faster than ever and you’re trying to innovate.

Let me give you an example: say that you’re running a development team and they’re working late hours, 9 or 10 in the evening and a developer’s got a defect that they’re really trying hard to fix and they just can’t get it to work and they happen to find an open-source library out on the web that fixes their problem. They download it, they test it, it works, it compiles and now it’s 10:30 and they’re ready to go home. Now, do you want to depend on the developer remembering the next day when he rolls in at 8 or 9 AM that he pulled that library down, that he used it and it’s now part of your software solution?

The reality is things slip through the cracks when you’re relying on manual reporting. You also probably don’t want your developers to spend all their time combing through the code at the end of the project identifying all the things that they pulled in or the things that they ripped out. It’s much easier to have a machine do it for you by scanning the software code automatically.

Who assumes responsibility for open source in your organization

Now, maybe you don’t want to have your developers do that, that’s a task that you want to give to your project managers and I’ve certainly seen companies that have had their project managers manually report all the dependencies that their projects have on open-source software. I used to have one that sat in the office next to me and he always dreaded the end of a project as we got toward a ship cycle because he had to go and manually fill out the certificate of originality. He had to go around and ask each developer what they used and whether the information was accurate and he had to trust those developers, those same developers that were working at 10 o’clock at night that what they remembered was actually accurate.

Now let’s widen the aperture a little bit more. Say you don’t do all your own custom development. What if you use a third-party to do custom development? In the mobile space, I’d say about two thirds of the clients that I talk to have somebody else write their mobile apps for them. Are you going to trust that they know everything that they’ve put into that code that they’ve delivered to you? That they know exactly what’s in it? That they’re as diligent as you when they don’t necessarily share the risk?

Let’s take another scenario: what happens if your company buys another company? Are you willing to take the chance that those developers were as diligent? That those project managers were as exacting as what you want your own developers to be?

The reality is we’re all just one acquisition or one third-party outsourcing agreement away from having that mobile examination of open-source dependencies breakdown. You need to be able to very quickly automate it. You need to be able to make it work as early as possible in the software delivery cycle and you need to be able to depend on the precision of machines and software to be able to accurately report what’s actually in your code.

Previous Article
Top 10 BSD Licenses’ Questions Answered
Top 10 BSD Licenses’ Questions Answered

After covering your top 10 questions about the GPL, the Apache 2.0 License, the Ms-PL, and the CDDL, today ...

Next Article
Are All Bugs Shallow? Questioning Linus’s Law
Are All Bugs Shallow? Questioning Linus’s Law

In Eric S. Raymond's seminal essay on open source, The Cathedral and the Bazaar, he defines Linus's Law, wh...