One of the core values of Sterblue says: “be bold”. Today we are proud to live up to that value by releasing the first generation of Sterblue Labs, our open-source and open engineering initiative. Sterblue Labs is the medium through which Sterblue Engineering teams will open-source key aspects of Sterblue technologies, starting today!
Some might say that being so open is a crazy idea for such an early-stage company in a technology dense competitive environment. And on one hand, as a co-founder of Sterblue, I can agree with that view, we are taking risks here! On the other hand, as the CTO of Sterblue and as an engineer, I am too thrilled by the opportunity to miss it!
In this post, I will try to explain this initiative simply. I am way too excited by the announcement to analyze it objectively, so I will try to just apply the rules blindly. We will start with Simon Sinek’s golden circles followed by a good old SWOT analysis, because that’s all I remember from my Business courses!
Sterblue Labs is a platform to open source nine key technologies that make Sterblue, well, Sterblue:
Our main public SDK:
- Sterblue SDK: Programmatic access to all features of Sterblue
Three tools that define what modern inspection means:
- Perception: A spatial 3D scene representation engine and algorithms
- Mobile: A mobile app to harvest data using all kinds of drones and sensors
- Curiosity: A scalable image recognition engine and AI training system
Three libraries to build the perfect Enterprise SaaS tech stack:
- Graph: A GraphQL API that is automatically created and easy to extend
- Superblocks: A React JS framework to compose micro frontends
- Synapses: A distributed business process workflow engine
Two sets of easy tools so solve difficult problems
- Libraries: A set of useful libraries open-sourced by Sterblue
- Infra: A boilerplate to deploy a Kubernetes infrastructure with Terraform
We are opening Sterblue Labs progressively:
- Opening the main website
- Opening the main pages for each of our nine technologies
- Opening the documentation of our SDK
- Opening parts of the documentation of each of our nine technologies
- Keeping some bits behind an authentication wall, but...
- Opening a registration page for people who’d like to get access to the materials
Publishing more over the next weeks and months:
- Officially launching these technologies one by one in the open-source ecosystem
- Publishing libraries and packages on NPM and PIP
- Publishing Github repositories of each of these nine technologies
- Opening larger parts of the documentation of each technology
Providing first-class open source over the next months and years:
- Fully opening the entirety of these technologies
- Sharing ownership of these technologies with the community
- Fully opening all documentation
- Offering technical support on these technologies
There are many reasons why we took this initiative, some more subjective than others. Companies use the open-source model because it’s beneficial to them, not only because they love sharing, so here is a list of the reasons why we made this choice:
- Marketing: We are proud of our technologies, we might be biased but we think we have good things to show to the world in general, and to our customers in particular. Sterblue Labs give us the opportunity to better communicate about our technologies.
- Sales: The depth of our technology can be a convincing insight when closing long term deals with companies that do not want to bet blindly about the future of critical infrastructure.
- Deep support: Our tech is quite deep, and we have deep integration with our customers. Our customer success and operations teams make our awesome support pages, but we needed a common place to share nitty-gritty technical documentation with all stakeholders.
- Developer platform: We need a way to open and host the public documentation of Sterblue SDK
- Attract talent: We believe that showing our nice and clean technologies is a good way to attract talent and build our engineering brand among tech enthusiasts.
- Retain talent: We all like to show up our work and share our accomplishments with the world. Labs offer a way for our brilliant tech team to display nice things they do and feel better than behind closed doors.
- Reduce our bus factor: By opening our documentation, we set ourselves to higher standards and get more motivation to write nice documentation and onboarding material, which allows Sterblue to reduce its bus factor by easing the learning curve on its technologies.
- Host our open ecosystem: We need a place to host documentation and code of our public open source technologies.
- Discover and prototype new technologies: Sterblue Labs allows us to test and prototype some technologies, on a smaller scale before actually using it in our product. For example, we were able to test various frontend libraries, infrastructure deployment strategies, and hosting tools that we might use in our product.
- The pleasure of sharing: Because in the end, this is still one of the main drivers of this decision. We were inspired by companies that open source awesome tools, such as Facebook and Airbnb, and we’d like to do the same, at our smaller scale.
- Our values: Openness and teamplay is at the core of Sterblue values, so this initiative aligns well with what we are
- We are contrarians: Other companies in our space don’t go the open-source way much, and we like to challenge the status quo, so let’s do what we believe in!
- Our feelings: We just have this feeling that this is the right thing to do for us right now, and we believe that it will lead to great results!
A little SWOT analysis
What better than a good old SWOT to finalize an article? Here are some final insights about that decision:
- Sterblue Engineering team developed a tremendous set of tools over the past 2 years for such a small team. We are proud of that and we think it is a strength of Sterblue Labs.
- These tools are modular enough that we can share their core, without giving away the “secret sauce” of Sterblue. Without this modularity and sane architecture, we would not be able to take this initiative.
- These tools are simple enough to be maintained by our team but smart enough to provide disproportionate value. The KISS principle at work. This allows us to believe these tools provide great value despite our small team
- Sterblue is still a small company. Our engineering team is outstanding but still consists of only 8 full-time employees and 4 apprentices and interns. So the scope of these tools and support is not to be compared with massive frameworks coming from FAANGs. They are neat little tools.
- We know from experience that open-sourcing and maintaining software can be a daunting task, and we know that our current resources are not enough to provide full first-class maintenance of what we open. We provide software as-is, with our best efforts, but for now, we won’t be able to promise stellar support on these tools we provide for free. That’s a goal for later though.
- What we are offering today is not a complete full open-sourcing of our technologies, and still on a small scale. We know this might be frustrating to part of the audience, but we will go at our pace, we have a product to build after all!
- The feedback of open source communities can sometimes be harsh, but it is the best and most honest technical feedback. The feedback will help us make our key technologies much more robust and give us a competitive advantage in the long run.
- The open-source ecosystem has helped Sterblue tremendously and will continue to do so even more. We are very thankful for the heroic effort of many in the community, including for example the teams at Graphile, Pytorch, Three and so many others. We hope to be able to pay all this back starting with this effort.
- Opening our technologies in the currently “closed-source” market we are in might have a transformative impact on the industry in the long run. We’d love to be even a tiny part of the changes that are happening in the Green Tech and Renewable Energy communities.
- Exposing our internal technologies this way is a risk to our reputation, which explains why not many companies in our space do it. We are confident in the quality of our work, but we know that any open source project can get heavy criticism easily. We are willing to take that risk and use the feedback as positive energy to get better ourselves.
- Security impacts are to be taken into consideration. We definitely think that security through obscurity is not an acceptable way to go, but opening part of our code might give security insights to potential threats. We take these risks seriously and strive to use defense in depth to prevent this.
- Tech giants and larger companies can sometimes apply predatory pressure on companies that are “too open”, as we have seen in the past. We try to strike the right balance between openness and protection. The structure of our technologies leads well to this approach: giving some building blocks does not help much in building the entire castle.
We are aware that in the end, we are just talking about a small scale experiment of opening the work of a dozen people over 2 years, so nothing to get crazy about at this point, and this article was probably way too long for this!
But hopefully, this will give ideas to others in the industry. Or maybe we will remember this article as the first milestone in a long history of open-source contributions from Sterblue. We are optimists at heart.