‹ Back to the blog listAn Open and Shut Case?

Open-source is great: You get fantastic apps developed by amazing people, all for free. Right?

Open-source offers terrific advantages: it's built by passionate developers and it’s free. Best of all, anyone can examine the code for problems. That means it's auditable… it can be vetted by the world at large. That's excellent.

Moreover, open-source projects can also become creative focal points, bringing together large numbers of talented people in innovative collaborations.

But like anything else, open-source does have certain shortcomings, which we've loosely labelled as 'Pizza effects' and 'You get what you pay for'. More about that in a few moments.

Proprietary or closed-source code also has strengths and weaknesses. Because it's sold commercially, budgets exist for things like quality assurance and full lifecycle support.

Furthermore, closed-source products are usually built with a development discipline that open-source projects rarely achieve.

Most of the time this results in fewer bugs, better usability and greater reliability simply because sales result in money to fund formal testing and future development.

But closed-source has weaknesses too: you can't examine the code to see what it's doing, and of course, it costs money.

What our users need is a simple, direct and 100% verifiable way to be certain that Merlin is both storing and transmitting their personal electronic data super-securely, while at the same time allowing us to protect the investments we’ve made in innovations like the Kahuna™ Network and the personal Synetic™ analysis engine that's built into every copy of Merlin.

That allows us to charge just enough money for our products and services to pay for network servers and ongoing development, while at the same time opening up for public scrutiny all the code that deals with information custody and security.

Fortunately, there is a proven means to accomplish this: encryption plug-ins.

Merlin itself is closed source, but encryption is supplied by third party open-source plug-ins which are vetted by the world at large.

Additionally, to insure Merlin is using them correctly, we supply test suites with defined inputs and outputs that can readily be verified.

And to make sure Merlin is not otherwise making secret copies or sending information anyplace it's not supposed to, we publish precise instructions (Contact Us) about how to put the app in a sandbox and monitor its resource usage, including network connections and storage consumption.

Pizza Effects

Picture three brilliant programmers coding part of some fantastic open-source project late one night. The doorbell rings, it's the pizza delivery! Instantly it becomes about coke and pepperoni, perhaps seasoned with some off-color jokes.

And that's it for the code... the programmers just stop, often without making notes or doing anything else to help them mentally reconstruct that fragile crystalline structure that is complex program logic.

An hour later everyone is full and tired, so they decide to resume the next time. The problem is, being human and not having to answer to any sort of boss, it's rare to find volunteers following development disciplines, writing unit tests, and remembering to run them.

Subtle bugs and partially implemented features routinely fall through the cracks. And all too often, so does any sort of reliable documentation, as anyone who has worked closely with open source can tell you.

These pizza effects result in fragile code, and plague many open-source projects (yes, there are some brilliant exceptions, but not very many). That's not the kind of product we want to give to our users, most especially given how central digital life has become. It's too risky.

Enough Eyeballs?

Another common assertion about open source is the supposed safety of the concept that 'given enough eyeballs, all bugs are shallow'.

The thing is, all too often this is a goal, not a description. And it's usually not achieved. If it were we would not have seen truly serious problems like Heartbleed or the Apache Struts vulnerability.

Just because there are many people looking at the code of an open source project does not mean they are qualified to find security vulnerabilities. Rigorous (and costly) quality control and penetration testing are also needed, not just sheer numbers.

It's especially instructive to listen to those who are on the front lines of open-source development every day. You can't help but think about it when you read what they have to say. Open source really does work, but only if you use it very wisely. And very sparingly.

You get what you pay for

Just because we now have the internet and a sea of smart devices, and just because some people are willing to work for free on things like open-source projects, it doesn't somehow override fundamental economic realities. It's a cliché, but it's also undeniably true that in life you get what you pay for. Another brilliant way to phrase much the same thing is, 'If you are not paying for the product, you are the product'.

Because it's more difficult to make money from open-source (at least not from direct ownership of intellectual property), it's also more difficult to find ways to enforce best practices — often there's no money to pay for comprehensive testing, third-party security analysis or failure point detection. Design consistency is often poor. And intellectual integrity suffers as people drift into and out of such projects. It happens all the time.

So how are we different?

We're greedy, but not financially. Our apps have all the sophistication of programs that sell for hundreds of dollars, and yet ours sell for 5 or 10 bucks. Many are even free.

We want the best of both the closed and open-source worlds, so we've designed a hybrid approach.

Our encryption technology is all open-source, provided by your choice of independent open source projects, but our application logic is closed.

That allows us to protect our intellectual property while empowering anyone to verify that information is protected by multiple layers of state-of-the-art encryption.

Using straightforward techniques, technical people can verify that Merlin does not leak information.

They can also confirm there is no IP address information in any delivered package (we don't need it because by design we don't use IP addresses for the internal routing of data inside the Kahuna™ Network).

We also publish simple procedures to make sure they can verify that our products are not leaking any data by creating temporary files or connecting to anything on the internet they are not supposed to.

Although our apps are either free or very low cost (and they will forever stay that way), we do charge a little bit for the Kahuna™ Network (servers and bandwidth cost money). But it's not a lot.

For example if you use Merlin as an average user (a few hours a day) and you buy one 50GB Kahuna™ card for about $38, it will last you more than a year.

We're making it as cheap as we can while still charging just enough to maintain servers and pay the rent (and eat, just like anyone else).

Finally…

Before anyone sends us comments about this or that really great open-source project, I want to make it clear that there are some stunning exceptions — tight and truly disciplined development efforts that consistently deliver solid software.

And yet, it's precisely these exceptions that prove the rule, because if you look behind the scenes at impressive products like MySQL (just to pick one example), you'll find a profit-making company (Oracle in this case) injecting money - not into the code itself but rather into the management and control of it, creating just the sort of discipline needed to prevent pizza effects.

But why do they do that?

Often it's simply because the open-source project enhances some other part of their closed-source, profit-making business. As their open-source customers' needs grow, they already have a captive audience to funnel into their commercial products.

So although what you get may be initially free, and assembled with care, it's designed with a growth path that leads you straight into their commercial product line.

You'll discover your free open-source system has 'scale limitations', or 'restricted security options', all of which can be effortlessly removed by… get ready for it... purchasing their more powerful proprietary solution! Often for lots of money, which people become willing to pay as their needs and budgets grow to exceed the capability of the initial open-source solution.

Of course, there are variations on this theme — some open-source projects give you the product for free, but charge heavily for supporting it, either fixing what shouldn't have been broken or explaining what should have been clear in the first place.

Mostly though, it's just a matter of take it or leave it — if it works, great, if it fails, well, sorry 'bout that; post your problem in our user group and we'll get to it next year. Maybe.

Mind you, I'm not pointing fingers at anyone specifically, including not at Oracle / MySQL — their products are great and they help a lot of people. I'm just trying to give you an idea of what's happening behind the scenes at some open-source initiatives.

Remember, if you are not paying for the product, you ARE the product. With Merlin and Kahuna™ you pay a just little, but you get a whole lot. It's a superb cost/benefit ratio.

Contents