Paul Müller is the CTO and a co-founder of adjust. He is in charge of building and scaling adjust’s technologies.

Mobile SDKs are, for most publishers, a necessary evil.

Whether you're trying to integrate analytics, cross-promotion, tracking, monetization or payments, your first step is most often to inject a third-party SDK into your codebase.

This much-maligned piece of software drives developers, operations and marketers alike up the wall - from creating well-defined operational specs that often change to soiling your product code with unspecified external components.

Much of the tension stems from the fact that SDKs are binary, black boxes that go into your precious code. To fix this, companies are looking to go open source.

Ultimately, the precompiled SDKs were, at one point, source code just like your app itself. If you could just integrate the plain source code, it'll behave and compile natively into your app.

With an open-sourced SDK, you're working with code you could have written yourself and which you can understand by cracking open the hood.

Open-source SDKs do exist, but they are exceedingly rare. Yet, if it's so convenient for developers to integrate, why would a business decide to not open source their SDK? Why are precompiled SDKs so prevalent?

Dispelling the fear of stolen code

The most obvious answer that comes to my mind is that people are scared that when the source code is open source, someone will steal it and hence steal their business. The SDK is intellectual property, so it's not unintuitive.

This would be valid if the SDK was a standalone product on its own. But it generally isn't. Analytics and tracking require extensive and sophisticated back ends, with internal APIs communicating with a multitude of services and performing complex computations at very high speeds. Ad networks require ad servers, and a big line of advertiser clients.

Payment solutions put most of their efforts into ensuring back-end security and compliance with stringent regulations.

Sure, you could steal the source code of an SDK, but you'd still need to replicate the data center, the backends, the APIs, the database and so on. The SDK itself is not a barrier to entry.

More sinister intentions?

Another reason why providers might be hesitant to go open source is that the SDK could potentially be altered. You can't tamper with the code in a precompiled binary, which you could theoretically do given the actual source code. Again, this makes intuitive sense, but let's dive into it a little.

With an analytics or tracking SDK, you could largely only affect your own dataset, for which you're paying. Ad networks may be concerned that a publisher might alter the SDK to report false impressions and clicks. But advertisers today really care about installs and purchases, which clearly can't be falsified with a modified publisher SDK.

In some sensitive types of systems, like payments, this could be a theoretical concern. A clever fraudster could perhaps more easily file false charges. Such a fraudster - crafty enough that they could avoid your other security layers and get enough users that it'd be profitable - probably wouldn't be much deterred by the black box SDK, either.

Ultimately, while we may intuitively think there are good reasons to precompile an SDK, we see upon closer inspection that these ideas are distinctly shaky.

Behind closed doors

I struggle to see any other reason, except for one, to precompile your SDK: You don't want other people to see your source code.

At best, that means it's badly written. At worst, that means it's doing something that you don't want anybody else to know about.

Without extensive investigation, you can't tell what the precompiled SDKs are up to in your app. It's exceedingly easy to wire a binary black box SDK in such a way that you, as the developer, would never know what's going on inside.

Not long ago, it was common wisdom that publisher SDKs from ad networks had a habit of looking for other SDKs in the app, and adjusted their CPC rates accordingly.

What happens when your app has additional permissions from the user to look at telephony settings or otherwise? In this case, a precompiled binary could completely opaquely poll those same system calls to collect additional data.

Now, most people who build precompiled SDKs are not evil, nor plotting schemes behind your back. Lacking malicious code, most of your providers do not have any valid reason to hide the source code of their SDK. Yet they do because it's common, and because it appears wise at first glance.

If we were to increasingly insist that our providers provide their SDK as open source, we would be able to make significant strides in the transparency and openness of the systems we distribute to millions of app marketers, and billions of smartphone users, every day.

Not to mention that you wouldn't hear a peep from your engineers when you want to try out a new tool. Perhaps that time is now.