idea → development → success (short claim)
At Cookielab, we use and contribute to many open source projects (OSS).
Our primary motivation is not necessarily to give back to the community (which we care about greatly). The fact is that we use open source tools to help us to be more productive, and we usually use them for client-facing work.
By making them open-sourced, and keeping them maintained, we bring great value to our clients because they don’t have to maintain and take care of the maintenance themselves. They get that for free. Our OSS projects are inherently “opinionated” in that they may not be for everyone. They’re based on our collective view of how to make great software, and we’re always looking for better ways to work. By default, it might not be created for universal use, since it’s opinionated and based on our coding standards and style of work.
We always think twice before we create a new OSS project. We consider other projects that are at our disposal at that time. When it looks like we are about to create something that is just a tiny bit better than another project, we usually opt for creating merge requests before forking it, or starting new projects from scratch.
Last but not least, the project needs to solve real-world problems - the likes of which we encounter in client-facing projects. There is a lot of upside for clients in this approach, as more projects use the OS libs, it brings more attention. That means more support and maintenance.
Enough theory, here are a few of our projects:
We have our own docker images based on Alpine Linux. For example, we have images for Node.js, AWS CLI, Kubernetes CLI (kubectl), and more. The main reason we build our own images is because these images do not use root user in runtime, but we also like them because we have more control.
We are making regular updates, and can update a library or package when there is a fix for a brand new CVE.
A Pg interface built as a mesh of several Pg libs. It’s based on Pg lib and uses Pgpool, Pgstream, Pgquery, and more. The main benefits of this project are recursive transactions and template string tags reused from other projects.
This package contains an explicitly defined set of strict Eslint rules for Typescript. It uses multiple ESLint plugins. The code style tries to be as strict and defensive as possible to avoid unwanted side effects, and increase code readability. You could say that this is “highly-opinionated” as described above. We use this across all of our projects.
…
These are projects we are most proud of, but it’s not everything.
As you can see, we host our projects on Gitlab and not Github. We used to have our OSS projects mirrored from our self-hosted Gitlab to Github, but we found that it was not the best setup for us. Because accepting MR/PR and managing issues (among other things) on two systems was painful, we decided to migrate our OSS project exclusively to Gitlab.com.
This decision was made because we use the Gitlab ecosystem on other projects. For example, we don’t need to learn how Github Actions work because we can use Gitlab CI pipelines similarly to how we use them on other projects.
What is your view or your company’s policy for open-source? Let us know on twitter - @cookielab.
And follow us on gitlab.com to get up-to-date information about our projects. We are looking forward to your merge requests and feedback!
