Why startups should release their code as open source

Dokit wondered whether giving away its knowledge as open source was a bad business decision, but that choice has been the foundation of its success.
170 readers like this.
open source button on keyboard

Opensource.com

It's always hard to recall exactly how a project started, but sometimes that can help you understand that project more clearly. When I think about it, our platform for creating user guides and documentation, Dokit, came straight out of my childhood. Growing up in a house where my toys were Meccano and model airplane kits, the idea of making things, taking individual pieces and putting them together to create a new whole, was always a fundamental part of what it meant to play. My father worked for a DIY company, so there were always signs of building, repair, and instruction manuals around the house. When I was young, my parents sent me to join the Boy Scouts, where we made tables, tents and mud ovens, which helped foster my enjoyment of shared learning that I later found in the open source movement.

The art of repairing things and recycling products that I learned in childhood became part of what I did for a job. Then it became my ambition to take the reassuring feel of learning how to make and do and repair at home or in a group—but put it online. That inspired Dokit's creation.

The first months

It hasn't always been easy, but since founding our company in 2017, I've realized that the biggest and most worthwhile goals are generally always difficult. If we were to achieve our plan to revolutionize the way old-fashioned manuals and user guides are created and published, and maximize our impact in what we knew all along would be a niche market, we knew that a guiding mission was crucial to how we organized everything else. It was from there that we reached our first big decision: to quickly launch a proof of concept using an existing open source framework, MediaWiki, and from there to release all of our code as open source.

In retrospect, this decision was made easier by the fact that MediaWiki was already up and running. With 15,000 developers already active around the world and on a platform that included 90% of the features we needed to meet our minimum viable product (MVP), things would have no doubt been harder without support from the engine that made its name by powering Wikipedia. Confluence, a documentation platform in use by many enterprises, offers some good features, but in the end, it was an easy choice between the two.

Placing our faith in the community, we put the first version of our platform straight onto GitHub. The excitement of watching the world's makers start using our platform, even before we'd done any real advertising, felt like an early indication that we were on the right track. Although the maker and Fablab movements encourage users to share instructions, and even sets out this expectation in the Fablab charter (as stated by MIT), in reality, there is a lack of real documentation.

The first and most significant reason people like using our platform is that it responds to the very real problem of poor documentation inside an otherwise great movement—one that we knew could be even better. To us, it felt a bit like we were repairing a gap in the community of makers and DIY. Within a year of our launch, Fablabs, Wikifab, Open Source Ecology, Les Petits Debrouillards, Ademe, and Low-Tech Lab had installed our tool on their servers for creating step-by-step tutorials.

Before even putting out a press release, one of our users, Wikifab, began to get praise in national media as "the Wikipedia of DIY." In just two years, we've seen hundreds of communities launched on their own Dokits, ranging from the fun to the funny to the more formal product guides. Again, the power of the community is the force we want to harness, and it's constantly amazing to see projects—ranging from wind turbines to pet feeders—develop engaging product manuals using the platform we started.

Opening up open source

Looking back at such a successful first two years, it's clear to us that our choice to use open source was fundamental to how we got where we are as fast as we did. The ability to gather feedback in open source is second-to-none. If a piece of code didn't work, someone could tell us right away. Why wait on appointments with consultants if you can learn along with those who are already using the service you created?

The level of engagement from the community also revealed the potential (including the potential interest) in our market. Paris has a good and growing community of developers, but open source took us from a pool of a few thousand locally, and brought us to millions of developers all around the world who could become a part of what we were trying to make happen. The open availability of our code also proved reassuring to our users and customers who felt safe that, even if our company went away, the code wouldn't.

If that was most of what we thought might happen as a result of using open source, there were also surprises along the way. By adopting an open method, we found ourselves gaining customers, reputation, and perfectly targeted advertising that we didn't have to pay for out of our limited startup budget. We found that the availability of our code helped improve our recruitment process because we were able to test candidates using our code before we made hires, and this also helped simplify the onboarding journey for those we did hire.

In what we see as a mixture of embarrassment and solidarity, the totally public nature of developers creating code in an open setting also helped drive up quality. People can share feedback with one another, but the public nature of the work also seems to encourage people to do their best. In the spirit of constant improvement and of continually building and rebuilding how Dokit works, supporting the community is something that we know we'd like to do more of and get better at in future.

Where to next?

Even with the faith we've always had in what we were doing, and seeing the great product manuals that have been developed using our software, it never stops being exciting to see our project grow, and we're certain that the future has good things in store.

In the early days, we found ourselves living a lot under the fear of distributing our knowledge for free. In reality, it was the opposite—open source gave us the ability to very rapidly build a startup that was sustainable from the beginning. Dokit is a platform designed to give its users the confidence to build, assemble, repair, and create entirely new inventions with the support of a community. In hindsight, we found we were doing the same thing by using open source to build a platform.

Just like when doing a repair or assembling a physical product, it's only when you have confidence in your methods that things truly begin to feel right. Now, at the beginning of our third year, we're starting to see growing global interest as the industry responds to new generations of customers who want to use, reuse, and assemble products that respond to changing homes and lifestyles. By providing the support of an online community, we think we're helping to create circumstances in which people feel more confident in doing things for themselves.

Tags
User profile image.
Wikifab and Dokit co-founder

7 Comments

Clement:
An interesting argument on the benefits of open-source, particularly the bit about building your "... startup that was sustainable." However, the practical aspects of your story are missing.

We all want opportunities to create, fulfilling work, good teams and happy clients. But we also must know, in a measurable way, how effective our plan is at monetizing our efforts and actions. This is most true during the startup phase.

Are we realistically evaluating our products and services? What is our value-add proposition to our clients? Do we capture or waste value?

Are we devaluing our products and giving away our capital to third parties through advertisers' badging and revenue-stream deflection?

These issues seem impersonal and cold in the context of our creative fires, but answering them properly leads to sustainability beyond starting up!

thanks for the useful article

Interesting point of view. I agree in many parts and I would add that opening the code gives us a way more better perspective re technical debt n our code.

useful article.

Good work. Keep it up!

useful article

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.