Why Open Source Software Runs In The SAFE Network DNA

Photo by Alex Holyoake on Unsplash

Last weekend, many of the team headed across to Brussels to attend FOSDEM, the annual get-together of the free software and open source community. The open source approach to development lies deep within the DNA of MaidSafe. It’s a crucial part of both how and why we do things the way that we do. But what does that mean in practice?

What is Open Source Software?

At the most basic level, software is just a collection of ones and zeros. And a software program is little more than a language that instructs computing devices to perform specific tasks. For most people in the world, life online is experienced only via what appears on the screen in front of them, whether that’s mobile, tablet or laptop. But of course, the real magic lies in the ones and zeros.

Throughout the history of software development, many companies have worked hard to protect themselves from their competition. Many modern businesses rely on their software for their profits. And the traditional way for business to defend itself is to protect via secrecy. So in the early days for many, it was all about building software, protecting the source code and relying on intellectual property to defend that ‘secret sauce’.

All well and good. Or is it? Software engineering is built on very different foundations to the more traditional business models of the past. For a start, the marginal cost of producing another set of digital ones and zeros is….zero. As soon as an idea is cloaked in digital clothing, it’s part of The Great Copying Machine that is the internet.

In other words: the weapons of restrictive competition that worked so well in the past don’t translate online.

The Dawning Realisation

Of course, that certainly didn’t stop companies from going down that route regardless. If you’re of a certain age, it’s easy to remember Microsoft’s constant battle against the Windows OS pirates. But it’s become increasingly clear that this wasn’t the only option — and a number of different approaches have developed during the past few years to challenge that belief.

The starting point is common sense. Imagine two groups of developers: one has 100 members, the other 100,000 developers. Now let’s have a bet: which group is likely to be the fastest at catching and fixing any bugs in the software? It’s pretty clear: the wider the pool of talent, the more chances you have to pick up on things going wrong.

But that’s not all. That group itself is likely to also include a greater number of highly focused problem-solvers (i.e. developers). Now tell them that there’s a problem somewhere. Or maybe that they can’t do something.

If you ever worked with developers (or are one), you know what’s coming. Not dissimilar to Cunningham’s Law, you’ve just stumbled across the easiest way to incentivise people to find a solution. So, as our focus online has evolved over the years from simple banter on bulletin boards to actively relying on software to carry out many of the most crucial functions in daily life (think financial transactions, identity theft, security of digital and physical assets), we see the mounting cost of critical failure. So it doesn’t take long to see the appeal of having an exponentially larger pool of talent to work with when it comes to making your software resilient.

The Process of Creation

So open source is good for bug-catching. But what about new ideas?

In general, innovation comes down to one of two options.

Number One: Build a skunkworks-type model. Close the doors and hide everything from sight until The Big Reveal! Explode from nowhere with your perfectly crafted software that has solves a massive problem for a corner of the world, make a ton of money and retire to the Bahamas. Congratulations!

The reality to this approach is quite different. After spending months or years building the foundational parts of your software, re-inventing the wheel in many cases, you burn through piles of cash and release your product — only to realise that the world never really cared in the first place. Or, if it does, someone else might already have come up with a better solution

So What’s The Answer?

Number Two: rely on software that others have built and tested. Improve it where possible — and give those improvements back to the wider community to do with as it wants.

It may be counterintuitive — but in a huge number of cases, this alternative is far more compelling. And it’s not new. The idea of closed versus open ecosystems online is a battle that was won decisively back in the late 1990’s when AOL/Compuserve’s attempts to provide services via the Walled Garden approach were steamrollered by the open and permissionless nature of the World Wide Web.

And not only do we all collectively benefit from software when ideas and quality control can come from anywhere around the world. When it comes to security-critical code, the greater the number of reviewers the better. Why would you not want to test the resiliency of your code in the face of the strongest possible attack? Because as soon as you go ‘live’ into the wild of the internet, you can guarantee that attack will come. We also now have systems in place that ensure that critical, foundational software programmes can be ‘locked open’.

The World of Open Source Licensing

Whilst building the SAFE Network at MaidSafe, we’ve always been crystal-clear: you can’t build a permissionless, decentralised peer-to-peer autonomous next generation network unless it is open source. Whilst the roll-out of the Network will see a number of different stages, there are two key ones to focus on here: the release of the SAFE Network, built on the SAFE Fundamentals and the Decentralised Applications (commonly known as DApps) that will run on the Network.

The SAFE Network ensures that the foundational core software for the Network is locked open. We do this by licensing the core libraries under a GPL v3 licence. That ensures that whatever anyone develops based on that licence must also be provided by them open source. This prevents someone coming in, forking the code and setting up a SAFE Network with the same code but with restrictive rights — for example, Google deciding to run a closed source version of the Network.

However, when it comes to Crust (the way computers connect to each other) and the SAFE API’s (the way that software developers can interact with the Network), you’ll find that these are licensed either MIT or BSD licences. These are known as permissive licences because they are free and have minimal requirements about how they can be redistributed. These simply require attribution but enable individuals to use the software to build their own, proprietary projects on top of.

Taking this licensing approach in the SAFE Network prevents anyone from taking the core code and using it for personal gain in a way that would exclude others. But it also gives the flexibility to others who want to build ventures on top of the Network once it’s live.

The open source foundations of the SAFE Network are vitally important to its continued success. It enables us to keep the core platform open to everyone whilst providing flexibility to application developers. We’re convinced that being community-led will help the Network to prosper and as a result, we’ll continue to protect its open source principles forever.

The Future

Back in 1675, Sir Isaac Newton spoke of seeing further by ‘standing on the shoulders of Giants’. At its core, the open and permissionless nature of our work is not simply a nice-to-have. It’s an essential component. Because by breaking down the barriers between projects, you’re in a world that encourages you not only to work with others — but also it ensures that every effort can be used somewhere, by someone. The unfinished attempts of any project can be picked up and completed by another.

It doesn’t make sense to work at solving mankind’s current digital problems if they’re built on weak foundations. That’s exactly what centralised data stores with their security weaknesses and broken privacy represent. We need to build the best technology possible. And that’s why we’re committed to open source development and keeping those gates open. Because this is work that’s far too important for us to do on our own. It’s a job that needs all of us to do our part.