Let’s be honest: we’re all concerned about our corporate secrets. What we build, how we build it, with whom, with which technology and which twists. Or we used to be, because there’s an alternative that radically breaks with tradition: build in public. This is about what this means for a company like WunderGraph, and why we took the leap.

Why secrecy dominates our thinking

One of the hardest things to learn for kids is how (and why) to keep a secret. It’s not a concept that’s hardwired into humans, it’s something that we have to learn and adopt as a habit. Once that learning process is done, it is very hard to let go of especially since we have lived by its rules for so long. Don’t tell people anything unless you can trust them. And even then, better keep important things to yourself.

It’s especially tough to decide against secrecy as it’s a condition with a negative preemption: you do not get a positive feedback by keeping things secret, but you will always get a negative feedback if someone obtains and discloses something that you kept secret for a reason. This is only amplified by the disappointment if someone abused your trust.

At the same time, ironically, most of us long to disclose secret information. It’s no fun to hold secrets nobody knows about. Also, you cannot get feedback or another opinion on things only known to you – it’s you and the information, and this is not how you gain knowledge or grow.

So, what we usually do is to form an “inner circle” or layers of people who have access to confidential information - friends, family, colleagues, the company. As an entrepreneur, you will decide who gets access to which information and maybe even install an access and rights management system so nothing goes wrong.

What we are trying to achieve by secrecy in software companies

You can roughly divide the goals of secrecy of a company into four categories:

• Privacy: Protect customer and personal data
• Compliance: Keep confidentiality where it is a legal requirement
• Security: Prevent unauthorized access and exploits of inside knowledge
• Competitive advantage: Conceal how your product works and what’s up next

It’s undisputed that privacy, compliance and security are absolutely legitimate reasons for not disclosing confidential information, so let’s focus on the competitive advantage and on parts of the security rationale.

Many companies strongly believe that what they are building and how they are building it must remain confidential. After all, what if the competition knew! Surely it must be a huge risk to be open about what you do, and what your plans are for the future. This information must never leave the company, and employees must be bound by restrictive clauses in their contracts not ever to say a thing.

Unlike traditional industries where this often is a reasonable strategy (think auto makers, defence etc.), the world of software follows different rules, so it’s worth to rethink this paradigm.

How open source defies secrecy and improves security

When people and later companies started to release software as “open source”, meaning disclosing the source code of a given tool for anyone to analyze and modify (license permitting), it was a revolution and contradicted the secrecy paradigm.

How could software whose code was accessible to anyone, even the worst hackers on the planet, ever be used safely? There hardly was any analyst back in the days who gave this weirdo, hippie-like concept a chance (which now is an industry generating more than 22 billion dollars in annual revenue today, growing almost 20% each year)

Actually, the very fact that the software code is not a secret helps to increase its security. People working on the code will find, highlight or even eliminate vulnerabilities by contributing fixes and amendments. Given a lively community, this usually is more efficient and faster than having a small company like a start-up doing all the work itself.

And even if people do not fix things, simply by calling out vulnerabilities, they can prevent people from using insecure software or put the pressure on to get things fixed by the code caretaker. If it’s public, there is no way to hide weaknesses. The more widely a software is used, the more attention it will receive.

So we see that in some cases, like in the open source world, it can be quite beneficial to everyone to disclose software. Can we even take this paradigm one step further to not just build better code, but provide the best solution through developer and customer experience?

The next level: Build in public

At WunderGraph, we decided early on that we wanted to build a lively open source community around our API integration and management SDK as open source under a friendly license. For something as fundamental to online services as API integration and management, we wanted to make sure that every developer could take advantage of our revolutionary approach to spend less time on APIs and more on value creation. At the same time, we’re humble enough to acknowledge that we can’t know or build everything ourselves.

Taking this one step further, we decided to build our upcoming serverless solution “WunderGraph Cloud” in public. We believe that by applying the open source paradigm to product development as well, we can create the best possible product that really solves problems relevant to our users and customers. At the same time, we also leverage the aforementioned security advantage by not building a black box you have to trust blindly.

This, of course, demands a level of openness that’s still unusual in any business. We disclose a roadmap, a feature plan and solution techniques that will also provide valuable insights to our competitors - but there are two aspects to consider which may make this work for your company as well.

Firstly, the benefits from optimizing the solution for true acceptance and building trust and traction with our user base outweighs the risks. Yes, we may be called out on blowing a timeline and yes, we may have to backtrack and try a different approach sometimes - but at the end of the day, our users feel the energy and passion we have invested into building something that makes their lives easier. We also expect the adoption of such a solution to be much easier for users as they’ve been a part of its creation.

Secondly, we don’t worry about our fellow players in the field. Just because someone starts building something doesn’t mean everyone else will do so right away, too - every company has different priorities, different customers, different skills. And even if a competitor was to build exactly the same product, this doesn’t mean that it is able to compete with yours by definition, and the market may simply be big enough not to turn this into a problem.

On a more philosophical level, we also believe that building in public has the potential to inspire others to build something amazing on their own or with WunderGraph, and we certainly don’t mind the attention this will generate with users and talent alike (did I mention we’re hiring ? :).

This approach may seem odd now, but its acceptance might grow over time as did the open source movement.