Thunderdome has been adopted by thousands of agile teams worldwide, spanning industries from finance and gaming to healthcare and beyond (though I’ll refrain from naming specific companies without permission). Through building and maintaining this open-source project, I’ve gained valuable insights that I’d like to share.
The Origin Story: Solving a Real-World Problem
I began developing Thunderdome an open-source agile planning poker, sprint retro, and story mapping tool on March 11th, 2019, as a personal project driven by my years of experience with agile methodologies and software development processes. At the time, I was working as a software engineer at Bank of America, where our team used various tools for agile management. However, planning poker was left to individual teams to figure out. We were using a web application that was not only clunky but also had security flaws that allowed developers to see others votes before the reveal. Motivated by these challenges, I set out to create Thunderdome with clear objectives: it needed to be easy to use, fast, secure, and open-source. I chose to develop it in Go to enhance my expertise in the language. After several months of development, I proudly shared the first version with my team, who eagerly adopted it. The application gained traction as my peers shared it within their developer networks, and within a few months, I had several hundred users. Encouraged by positive feedback, I continued iterating on the application, improving the user experience and adding features to sustain growth.
Evolution of Thunderdome
Over time, I developed additional applications for Sprint Retrospective and Story Mapping. However, maintaining them as separate projects made user adoption challenging since they weren’t integrated with the planning poker tool. This led me to consolidate these features into Thunderdome, transforming it into a comprehensive suite of tools for agile teams. Later, I further expanded the platform by adding support for asynchronous daily standups.
Leveraging Open Source for Organic Growth
The project’s GitHub repository has been a valuable source of community engagement, with users contributing everything from bug fixes to substantial features like LDAP authentication that might not have otherwise been prioritized. Being open-source and free has enabled organic growth through word of mouth, search engines, and various online channels. Furthermore, the open-source nature of Thunderdome allows companies with strict data hosting requirements or specific configuration needs to deploy their own self-hosted instances.
Balancing Open Source and Business: The Monetization Journey
After several years of personally funding the hosting costs for Thunderdome.dev and seeing limited success with GitHub Sponsors donations, I decided to explore monetization options. The challenge was maintaining open-source values while ensuring existing features remained accessible. I initially launched a monthly individual subscription plan that introduced a premium feature for importing Jira cloud stories during Story Pointing exercises.
After a few months, I expanded the subscription model to include tiered plans for teams and organizations, offering access to both existing and new premium features. Throughout this transition, I maintained the original feature set in the free tier while ensuring self-hosted instances retained full access to all premium features. As of writing, subscription growth remains challenging, likely due to the open-source nature of the project and the availability of core features in the free tier. Nevertheless, I remain committed to building and maintaining the project, hoping that continued development of premium features will eventually attract more corporate subscribers.
Technical Architecture and Scaling Decisions
Software development is a constantly evolving industry with diverse solutions. Developers often specialize in specific tech stacks, and the open-source nature of many technologies influences both their adoption rates and community contributions.
The choice of Go as Thunderdome’s foundation was deliberate and has proven crucial to its success. Initially, while I chose Go to expand my expertise in the language, its characteristics made it an ideal match for building a real-time collaborative web application. Go’s performance characteristics stood out immediately. The language’s efficient garbage collection and low memory footprint meant that even a small cloud VPS instance could handle hundreds of concurrent planning poker sessions.
Looking back, Go’s performance characteristics, strong standard library, and community focus on simplicity have aligned perfectly with Thunderdome’s needs as both a cloud service and self-hosted solution. The language’s stability and backward compatibility have also meant near-zero maintenance overhead for version upgrades, allowing us to focus on feature development rather than dealing with breaking changes.
The decision to use Svelte for Thunderdome’s frontend was driven by a desire for performance and maintainability, though this choice came with interesting trade-offs for an open-source project. Unlike traditional virtual DOM frameworks, Svelte’s compile-time approach to reactivity meant our planning poker sessions remained snappy even with rapid vote updates and participant changes.
Svelte’s straightforward component model made it easy to build and maintain features like real-time vote tracking and retrospective boards. The framework’s built-in state management eliminated the need for additional dependencies like Redux or MobX, keeping the bundle size small and loading times fast. This was particularly noticeable in the story mapping feature, where teams can fluidly reorganize dozens of cards without any perceptible lag.
However, choosing Svelte over React created an unexpected barrier to community contributions. While the framework’s simplicity made the codebase more approachable for those willing to learn it, many potential contributors were more comfortable with React’s ecosystem. Several times, developers expressed interest in adding features but hesitated when they realized they’d need to learn Svelte first.
Despite these challenges, Svelte’s performance benefits and maintainability advantages have justified the choice. The framework’s reactive model has been particularly valuable for real-time features, where updates need to flow seamlessly through the UI. Loading times remain quick even as features have grown, and the codebase has stayed readable and manageable without layers of abstraction.
Looking Ahead
After six years of evolution, Thunderdome stands at an interesting crossroads. While the open-source foundation remains strong, the path to sustainability lies in developing premium features that deliver substantial value beyond the core offering.
However, this focus on premium features presents interesting challenges. I must carefully balance adding valuable premium features while ensuring the free, open-source version remains robust and useful. My commitment to keeping core functionality free and self-hostable remains unchanged – this approach has built trust with the community and drives organic growth that ultimately leads to premium adoptions.
Perhaps the biggest challenge ahead isn’t technical but strategic: crafting premium features that align with enterprise needs while staying true to the simplicity and efficiency that made Thunderdome popular in the first place. It’s a delicate balance, but one that I believe will secure the project’s future while continuing to serve the growing community of users.