Open Source
What is open-source software?
Open-source software is code that everyone has free access to; not only to use, but to analyze, alter, and improve. The code is released as a plain text file, and can be accessed on channels like Github. Integrating the code can be as simple as copy-paste, and you can change it yourself as with any word document, just in a different language. If you want to know exactly what such files look like, our SDK’s are available to view.
Closed-source (or proprietary software) also exists, and it’s the exact opposite to open - software whose source code is not published, and is not licensed to be altered.
So now we know a little about what open is, let’s move onto the good stuff. Here’s a top five list of the benefits of open-source:
It’s transparent
Let’s take attribution as an example. No matter who you choose, you will need to install an SDK to do it. So if you were to decide between a closed or open solution, what might sway your decision?
Both could offer a compelling choice, but the core benefit of open is that you can find out exactly how it works. A file which you can read and understand means knowing what you’re mixing in with your own program (and what you’ll be allowing access to). On the flip side, a closed-source project could contain anything, and there’s no means to check it (at least, without reverse-engineering the code.)
Independent bodies can review open-source work for you too, like a second opinion. These checks can be great for spotting potential problems, ensuring credibility of the code, and perhaps even finding a bug or conflict in the process.
It’s customizable
You can do whatever you like with our SDK. You can pull it apart, take out what you don’t need and add code which is directly applicable to you that improves upon the stock version. It’s also much easier to suggest feature updates, as open-source projects can receive direct feedback on the code, and change it if there’s something to be improved. With closed, while features can be recommended, users can’t suggest means of implementation, or provide feedback in such a meaningful way.
When it comes to bugs, open-source allows engineers on both sides to find the cause of a problem. With adjust, you may not even have to contact support if your tech teams know precisely what they’re dealing with.
It’s agile
Open-source is fast. Do you need to make changes quickly? Well, you can, depending on your needs. For example, as newer and newer iterations of operating systems are released, compatibility can become an issue. With open-source, you can keep up with the pace of development by discussing the issue, and reviewing other projects to find out how others have fixed similar problems.
It’s secure
Developing a closed-source project usually means that developers don’t want others to see their code. For most, this is a proprietary issue, but in some instances it could be a case of wanting to hide bloated projects, or in others it could mean there’s something extra that the developer doesn’t want you to know about. Whatever the case, with open-source, none of these issues exist - for one, code could not stay in circulation for very long if something harmful inbetween the lines.
It’s quality-assured
Because of the necessary transparency open-source projects need to be good, or they couldn’t survive. Closed-source only needs to function, because the products have somewhere to hide.
At adjust, we happily share the product that we’re proud of, in the knowledge that we need to maintain a high level of quality in order to undergo the scrutiny from both every client we work with, and from our peers too.
Who open-sources?
For examples of companies and groups that use open-source, Wikipedia has a long list of projects, which include auto manufactures, governments, and banks. In our list, we’ve picked out some of the more prominent examples:
MySQL, which likely runs your database.
Wordpress, which is almost certainly your site’s CMS.
Android runs on open-source software too, just take a look.
Furthermore, Google is big on open-source.
Microsoft opened up its .NET framework in 2014.
Apple, though protective of most of their work, open-sourced their iOS programming language Swift.
You can work on Facebook code at a whim.
And Amazon, while not necessarily leaders in open, are moving into the space with their software for deep learning.
Open-source software isn’t just for conglomerates, it’s also used to good effect in health care too, from providing eye tracking type-ware for those who suffer from ALS/MND to medical practices management software.
With all these projects putting their trust in open-source software, whether it be companies, governments, or even app attribution, it’s assured that open-source isn’t only safe, but also agile, economical, and transparent.
Challenging the misunderstandings of open
There are some objections to open-source projects, but a lot of them come from misunderstandings or misinformation. To clear this up, we’ll cover off some of the conceived pitfalls of open-source.
Isn’t closed-source safer?
Open-source may be available to everyone, but that doesn’t compromise your security, nor give away how you work or what you’re working on. Equally, closed-source software isn’t made more secure by the fact that it can’t be read by others (at least without serious engineering). Essentially, consider this: is it safer to know what something is made of, or not?
By allowing everyone to view the code, open-source projects can be scrutinized. With closed, a project could include something that you don’t know about, and you aren’t allowed to check.
Furthermore, while someone could find an exploit in open-source code, closed-source can be “reverse-engineered” (the process of taking a program’s binary code, and rebuilding it to recreate the original product). The code in this case would be just as exposed, it would just take longer to do so. Does this mean that one is more at risk than the other? Or would closed-source code give a sense of security that it doesn’t warrant?
In the context of working with adjust, (and as we’ve mentioned before) “mobile SDKs are…a necessary evil.” Whenever you want to track, your app needs a third party SDK (that is, unless you have created your own.) SDKs themselves are pretty rigid, and big too, and if they don’t work how they’re supposed to, then without access you’re reliant on support teams or working with documentation that may not be all that easy to understand.
With open, you know what you’re installing, and your developers can see what they’re working with - removing the possibility of buggy or malicious code - and making the work easier to integrate with your application. It’s almost as simple as copy-pasting the SDK into your code, as though your team had created it. This has a small benefit too, because you can document the process and repeat it with every new app you create and release.
Who can change open-source code?
In theory, anyone can alter open-source software, and while code should be easy to edit, it’s not as simple as logging onto Github and changing a file.
First you need to know the language, which isn’t an easy skill to learn. In fact, open-source makes learning that little bit easier, with newer coders being able to both understand larger programs and contribute in small ways to an overall project, boosting their skills. For those with more experience, open-source contributions provide evidence of good work done by an individual, akin to a portfolio. Most coders try to improve their own knowledge or credibility, as opposed to harming their reputation with destructive code. Only a tiny minority would want to cause harm, and a much smaller subset of that could.
Second, changes are subject to approvals: any edits suggested by a third party are vetted with care by the team who developed the original code. There are only so many alterations that can better the work already done, especially if the code has been open-sourced from day one. While there are always things that could be improved on in any piece of work, it’s not as easy as ratifying every change instantly - rigid approvals counter this issue.
And since we’re on this topic, while it’s true that anyone with an account to an open-source collaboration site can view the project, that doesn’t mean they can see the end product. What’s available is only a single piece of software, as yet unattached to a wider program, like a single cog before it’s added to a machine. adjust’s SDKs are viewable to all, but the same people won’t have access to your application (unless it’s open-source as well.) No-one can get to the code that ultimately makes up your app, just you.
What secures open-source code when it handles data?
All data, whether with us, or managed by someone else, is HTTPS/SSL-encrypted. That ensures that only you have access to the data. It’s the same stuff that’s used to keep bank transactions, emails and even WhatsApp messages private. In the case of adjust, we use a ‘shared secret methodology’, where data cannot be validated unless you have an app token (among other layers of security).
And just in case you weren’t quite convinced, even the code that encrypts your data is open-source. Millions of online purchases are made daily, without a second thought to the security of the user at this stage in the process, and all taken care of by open-source.