00:00:06.540
Hello everyone, my name is Rafał Cymerys. I work at Upside, which is a software consultancy and software house.
00:00:12.599
Last year, we took over an open-source framework called Spree as lead maintainers. I'm going to share some interesting stories about maintaining that framework, helping people scale, and ensuring our users are happy.
00:00:28.800
I drew the first part of my presentation from the Rails website, where they claim that Rails applications can scale from MVP to IPO without any issues. I put that into the context of building an open-source framework that other companies use to scale from MVP to an actual IPO.
00:00:48.600
A few words about Spree: it is an e-commerce framework, which is interesting because it isn't just a developer tool; it also contains a significant amount of business logic specific to the e-commerce domain. It has been built on the Rails framework, following its best practices for many years, and has been available since 2008—this year we are celebrating its 15th anniversary.
00:01:13.320
We became the third maintainer of Spree, following two previous companies that were in charge. I don't have a QR code to share, as I'm not aware of that trend, but I believe our GitHub handle is easy to type, so feel free to check it out if you haven't encountered Spree before.
00:01:37.740
Now, let me tell you a bit about how Spree started. As with any open-source tool, it begins with a commit. In this case, it was actually an empty dummy commit, and three comments later, we had something meaningful: the base of the Rails application. It's also interesting to note that Spree predates GitHub, which launched publicly in April of that same year. So, there's quite a lot of history in that.
00:02:19.680
Over the years, Spree has seen multiple releases, and although it may not have the highest number of contributors, it has a stable user base. It is used by many businesses of all sizes, from small mom-and-pop shops who want to launch a simple webshop to startups that use Spree to grow their operations. There's even a multi-million-dollar enterprise that utilizes Spree for its order management and inventory systems, showcasing the flexibility of the framework.
00:02:39.300
One notable trend we've observed over the years is that some businesses powered by Spree have adopted disruptive business models, such as subscription services. For example, companies like Dollar Shave Club leveraged Spree's customizability to implement their innovative e-commerce strategies, leading to significant growth in Spree-based applications. However, transitioning into this new era of e-commerce has not been without its challenges.
00:04:02.879
Every open-source product that gains traction faces similar challenges, but the degree of these challenges can vary based on the tool's functionality. We've identified three major areas that tend to be problematic: first, having a clear roadmap or vision; second, issues arising from upgrades; and third, the maintainability of custom code built on top of the framework. I will elaborate on these areas shortly.
00:05:14.520
The challenges affect not only users but also businesses relying on specific frameworks, leading to potential business risks. For instance, without a reliable roadmap or user trust, projects may become perceived as 'abandonware' or obsolete, which could deter adoption. Upgrades present their own issues, often leading teams to receive alerts about security vulnerabilities if their applications aren't updated, creating additional stress for developers.
00:06:05.400
Finally, maintainability poses a significant challenge, particularly for Rails and Spree, as both can struggle with how far a developer can push customization before it becomes unmanageable. While Rails enhances productivity with tools like meta-programming, excessive reliance on it can lead to complications. For example, many developers find themselves stuck with forks of older Spree versions, leaving them to deal with unforeseen issues and difficulties during upgrades.
00:06:32.100
As an open-source project evolves, it is crucial to keep everyone satisfied and ensure a smooth experience without hindering progress. One common challenge arises with maintaining existing compatible customizations as frameworks are updated.
00:07:01.080
For instance, if a new Rails update introduces breaking changes, existing applications may conduct audits to evaluate impacts. As maintainers, we see that some changes, while technically feasible, can result in significant disruptions to users if not planned or communicated properly. Our objective is to help users transition smoothly through upgrades while maintaining the integrity of their businesses.
00:07:37.919
Over the years, we've explored range solutions for tackling these challenges. First, we recognize the importance of having a clearly defined roadmap. Although some open-source projects thrive without one, we've observed that for those gaining significant traction, a roadmap is essential. It not only communicates the project's direction but assists contributors in aligning their efforts with project priorities.
00:08:12.840
Once we published our roadmap, we saw an increase in engagement from the community, as contributors felt more empowered to participate in specific initiatives that aligned with our vision. Projects benefit when contributors are afforded opportunities to create valuable improvements and suggestions.
00:09:00.600
Banding contributors together with common goals promotes teamwork and reduces chaos, helping to ensure that work aligns with the primary objectives of the project. However, upgrades continue to be challenging, as our users often prefer the latest versions, but the nature of business and resource limitations can create barriers. We've found that maintenance work involved in upgrades is often difficult to plan and budget, causing teams to stick with older versions.
00:09:48.480
Upgrades can complicate the process, particularly when breaking changes are coupled with new releases; users find themselves in situations where they can't allocate resources to implement new updates. That happened with frameworks in the JavaScript Community, leading many developers to reconsider constant rewrites of their code, signaling a broader trend of fatigue with frequent updates across various technologies.
00:10:29.640
As maintainers, we've actively chosen to take a conservative approach when it comes to implementing breaking changes. We've initiated several strategies to allow our users a more stable experience while keeping their installations updated as they transition to new versions of Rails and other core frameworks. Preserving a stable interface is paramount for our user base.
00:11:08.460
It’s essential to recognize that sometimes, maintaining compatibility means accepting legacy features that aren't necessarily sustainable. It’s not unusual for existing code to become a lifeline for users who depend on it, and we're aware that refactoring might introduce risks. We're vigilant in our decision-making and implement migration schedules that provide our users with sufficient notice to adapt to any upcoming changes.
00:12:01.800
We’ve faced various migration challenges, particularly concerning our APIs. Over several years, we've maintained an older version of the API that was less than ideal by modern standards. Although it's still utilized by popular applications, we have gradually started extracting legacy components into separate gems and encouraging users to transition onto improved versions.
00:12:30.660
As our project has matured, we've learned that patience and gradual adjustments are vital in making changes while keeping users content. It's critical to manage the approaches towards deprecation rather than forcefully rewriting major components at once, as this could alienate users accustomed to the existing structure.
00:13:40.860
In the realm of Rails, Spree began in 2008 and inherently adopted many Rails conventions, including the fat model/thin controller paradigm, resulting in various challenges. While this model allows flexibility, it can also become cumbersome when the complexity of the application scales.
00:14:28.679
As frameworks evolve, they often accommodate greater flexibility, with many options available for customization. It is through this approach that some of the more sustainable solutions are created. However, with added flexibility comes a burden of maintenance, especially when extensive monkey patching leads to unforeseen complications.
00:15:20.940
An interesting aspect of maintenance is the reliance on plugins and extensions linked to the core code. Developing an evolving framework while allowing developers to customize as they see fit has created challenges—not only for maintainers but also for users. Developers need to be careful not to override private methods that could lead to future complications unless they’re fully aware of the implications.
00:16:32.740
We have engaged in discussions within the community, considering the implications of introducing event-driven architectures and other similar shifts in framework design. As we assess this potential direction, it’s critical to balance our actions with users' experiences to avoid overwhelming change that could impair existing customizations.
00:17:41.819
Moving ahead, allowing for controlled customization while tracking user needs remains our primary goal. Collecting insights from users who have progressed with Spree enhances our decision-making process. Thus, careful decisions about organizational changes reflect our commitment to priorities that resonate with our contributors and users.
00:18:39.920
In summary, fostering an adaptable and sustainable project requires balancing the pace of change with user needs. Taking smaller incremental steps can yield better results by creating a more accountable framework and enhancing development practices for all users involved.
00:19:45.540
The discussion surrounding modern practices in software development is vast; as such, we encourage looking beyond our traditional approaches to draw inspiration from other successful communities, including JavaScript and TypeScript, where innovative ideas can lead us to build better, more robust projects together.
00:20:14.000
Thank you for your attention.
00:20:29.000
Are there any questions?
00:21:00.000
Thank you for the talk; it was very interesting. I am curious about how you collect information on how people are monkey patching Spree, and how do you decide what to refactor regarding dependency injection?
00:21:46.000
That's a very good question. We support many existing users, particularly once they reach a point of significant growth with Spree. They often reach out to us for support with upgrades or code refactoring, providing us valuable insights into what users do and the innovative ways they customize our platform.
00:23:12.000
Active involvement in the community also allows us to gather feedback directly. Users often share their experiences, especially when they realize that monkey patching might not be the scalable solution it once seemed.
00:24:01.000
Making these connections through discussions and collaborative consultancy enables us to prioritize new features and capabilities aligned with user feedback.
00:24:45.000
I'm curious—what are your thoughts on moving towards events in your internal discussions? It seems like there are some clear benefits, but I wonder what your conclusion has been.
00:25:38.000
It's an interesting concept; however, it could be quite a disruptive change for existing users. For now, we are focusing on smaller, incremental steps that do not disrupt the core behaviors that our users have come to rely on.
00:27:00.000
We feel events could introduce a lot of loose coupling, which could lead to challenges in understanding dependencies in the existing codebase.
00:27:45.000
While we haven't made significant changes yet, there have been attempts from the community to create event models in forks of Spree, but no clear consensus has emerged on how to best manage that.
00:29:00.000
As always, we appreciate these discussions, and we're actively considering user interactions while exploring paths forward.
00:29:51.000
Thank you all for your engaging questions.