This article is sponsored by Storyblok. Open source is at the heart of modern software development. As someone who has been deeply involved in community-driven as well as company-driven open-source, I have had the opportunity to experience its diverse approaches. This article explores what modern OSS authoring looks like. It focuses on front-end JavaScript tools such as TresJS, and tools that I’ve developed at Storyblok. Let me be clear, there is no universal playbook when it comes to OSS. Each language, framework, project, and culture has its own rules, workflows, and culture – and that’s okay. Open source is so adaptable because of these variations. The Art Of OSS Publishing Authoring an open source project begins by solving a problem that you face as a programmer. As your “experiment”, however, gains traction, you will need to address diverse use cases and maintain the simplicity of the original idea. TresJS is a good example. I just wanted to add 3D to Nuxt’s personal portfolio. But at the time, VueJS didn’t have a feature-rich, maintained alternative to React Three Fiber. I decided to make one. My portfolio is still unfinished two years after my library was launched. Community-driven OSS authoring: Lessons from TresJS Continuing to use TresJS as a case study of a community driven OSS project, its community has been able to contribute ideas, file issues (around 531) and submit pull requests (around 936) of which 90% made it into production. As an author, it’s the best thing to happen. It’s probably the main reason I fell in love open source. The constant collaboration creates a climate where new ideas can develop into meaningful contributions. It also has its own challenges. The more ideas that come in, the more difficult it is to keep the project focused on its original purpose. As authors, we have a responsibility to maintain the vision of the library — even if it means saying no to good ideas from the community. Over time, the most consistent contributors became a core group, sharing the responsibility for maintaining the library, and ensuring that it stays aligned to its original goals. Delegation is another crucial aspect to scaling a project. This is especially true for TresJS which has evolved into an ecosystem of packages. As the project grows, it becomes more important to distribute responsibilities between contributors. Delegation reduces the workload and empowers contributors by allowing them to take responsibility for specific areas. As a core contributor, it is equally important to provide tools, CI workflows and clear conventions in order to make the contribution process as simple and efficient. A well-prepared base allows new and existing contributors to focus on what really matters – pushing the project forward. Storyblok’s Perspective on Company-driven OSS: Now that we have explored the positives and challenges of community driven OSS, let’s move into a new realm: company-driven OSS. I had worked with open-source and inner-source in other companies, so I knew how OSS functions in a company context. My most meaningful experience came later, more specifically, earlier this year when I changed my role from DevRel into a full-time developer experience engineer. I say “full time” because I was already contributing towards Storyblok SDK ecosystem before taking on the role. Open source is a key part of how we work with developers at Storyblok and how they use our product with the frameworks they prefer. Storyblok’s goal is to make the Storyblok experience as simple, effective and enjoyable as possible, regardless of the framework. To achieve this goal, it’s important to balance the needs and goals of the company with those of the developer community. These needs often reflect those of the clients that they serve. One of the most challenging things for me is managing expectations. While the community may expect feature requests and bug-fixes to be implemented quickly by the company, their priorities could be focusing on stability and scalability and often strategic integrations. To maintain healthy alignment and mutual trust, it is important to prioritize and communicate clearly. One of the advantages of company-driven Open Source is the availability of resources. This setup can be a challenge, as it often involves dealing with legacy codebases – typically written by developers unfamiliar with OSS principles. This can lead inconsistencies in testing, documentation, and structure that require significant refactoring to align the project with open-source best practice. Community vs. company: Navigating The Spectrum I like to compare community-driven OSS to jazz music, which is freeform, improvised and highly collaborative. Company-driven OSS is more like an orchestra with a conductor guiding and coordinating the performance. Most OSS projects, if not all of them, fall somewhere on this spectrum. TresJS, for example, began as a community-driven project. But as it matured, and gained traction and momentum, structured decision-making – more typical of corporate-driven projects – became necessary to maintain focus. Together with the core group, we developed a vision and set goals for the project so that it could continue to grow without losing its original purpose. Interestingly, it is also true that company-driven OSS projects can benefit from the rapid innovation seen in community driven projects. Since joining the Storyblok team, I’ve implemented many improvements that were inspired by TresJS. Migrating TresJS to pnpm workspaces, for example, demonstrated how streamlined dependencies management could improve development workflows such as playgrounds and E2E — an approach that we gradually adapted for Storyblok’s ecosystem. The community-driven approach to testing in community projects influenced the transition of Storyblok testing away from Jest and towards Vitest. Vitest’s improved performance and developer experience was also a factor. Our switch from Prettier’s flat configuration to ESLint v9 with auto-fix helped consolidate formatting and linting into a single workflow. This improved developer productivity. Storyblok has incorporated even more granular processes such as modernizing CI work flows. The evolution of TresJS from a monolithic release to granular steps such as linting and testing, along with building, provided a blueprint for improving our pipelines at Storyblok. We also adopted continuous-release practices inspired by pkg.pr.new. This enabled faster delivery of incremental updates and testing package releases on real client projects in order to gather immediate feedback prior to merging the PRs. TresJS has also benefited from the experiences I gained at Storyblok. This ecosystem was more mature and had been tested in battle, especially when it came to adopting automated processes. We used auto-merge for minor updates and integrated Dependabot for keeping dependencies current. This freed up time for contributors to do more meaningful work. We implemented an automatic release pipeline based on GitHub Actions inspired by Storyblok workflows to ensure smoother and more reliable TresJS releases. The Challenges of Authoring Modern OSS We’ve discussed several challenges in this article. But if we had to choose one, it would be managing breaking changes and maintaining compatability. We all know how fast technology moves, especially on the internet, and users expect libraries to keep up. I’m not alone in saying that hype-driven software development is fun, but inherently risky. It’s not the best way to build reliable, high-performance applications, especially in enterprise contexts. Breaking changes exist. Semantic versioning is a way to make life easier. It is important to balance stability with innovation. This is especially important when introducing new features, or refactoring to improve performance, and breaking existing APIs. During my time at Storyblok, I learned the importance of communicating clearly. Changelogs, migration guide, and deprecation notices are all valuable tools for smoothing the transition. An example:

My first project as a developer experience engineer was to introduce @storyblok/richtext. This library for rich-text is downloaded around 172k times per month (at the time this article was written). The library was created during my time as DevRel. However, transitioning users from the previous rich text implementation across the ecosystem to the new library required careful planning. Together with my manager, I planned a multimonth transition that would include a retrocompatible period prior to the major release. This included communication campaigns and thorough documentation as well as gradual adoption in order to minimize disruption.

Despite all of our efforts, mistakes will happen. That’s okay. During the transition to rich-text, there were times when updates were not delivered on time or communication and documentation was temporarily out of sync. This confusion was addressed by providing timely support via GitHub issues and discord. These moments served to remind us that OSS authoring will never be perfect, even with semantic versions, modular architectures, or meticulous planning. Making mistakes is part of the process. This brings us to our next point. Open-source authoring requires a lifelong journey of learning. Each mistake is an opportunity to learn, and every success reinforces the importance of collaboration and experimentation. It’s not possible to do OSS in a “perfect” manner. That’s what makes it so great. Each project has its own workflows, challenges and quirks that are shaped by its community and contributors. Open source is flexible, dynamic, fun and, most importantly, impactful because of these differences. Remember that progress is more important than perfection, whether you are building something new or contributing to a project already in existence. Continue to contribute, experiment, and share your work. Each pull request, issue and idea that you submit adds value to your project as well as to the ecosystem. Happy coding!