The easiest way to get up and running quickly with XOOM, along with an explanation of our position on open source innovation.
We’ve decided to introduce a familiar way to learn the different components of the XOOM toolset—without the need to understand everything about our platform up front. It is our belief that all application frameworks should include a bootstrap that focuses on reducing undifferentiated heavy lifting. We’ve named ours XOOM Turbo and we will provide a more detailed technical introduction in the coming days. This post is intended to articulate our position in the open source JVM application framework space and how we see ourselves fitting in.
When developers evaluate which framework or toolset to use in an application ecosystem, either on the JVM or Node.js, as an example, they usually start by asking “How is this like X?” or “How is this different than Y?”.
We realize that these questions are important, however, by providing a concise answer, we are also stating that “We are a JVM framework that is greater than or less than X or Y”.
XOOM libraries were not built to satisfy these goals. In fact, XOOM was created on a set of guiding principles that were never intended to directly replicate or compete with commodity application frameworks. Rather, as with most open source projects, foundational ideas and principles drove XOOM to focus on capabilities and conventions for today’s application developers. With XOOM, you now have a way to accelerate adoption of our Reactive platform and more quickly benefit from our distinct value proposition: Domain-Driven Design friendly distributed computing platform simplifying Reactive, Event-Driven, Microservices Architectures.
By comparing ourselves to the popular alternatives, we inevitably enter into the ring with heavyweight contenders, such as Spring Boot. And because of this fact, it might be easy to see XOOM as a less mature choice—or worse, that it is our ambition to usurp Spring Boot. We want to make it clear, we just don’t see it like that.
Open source is not a Game of Thrones. Not all war metaphors need apply to open source projects. Open source is not an extension of capitalism. It’s an extension of democracy. And much like a real democracy, open source projects usually contain a lot of overlaps. These overlaps are usually not the result of some master plan, but rather, by doing things that make sense for a project’s long term viability. Sometimes the best possible idea is simply that, and as such, the best ideas should not be regarded as property of one ecosystem or another.
We, the maintainers and creators of XOOM, hold these stated values because they are both to our benefit and the benefit of the open source community as a whole. At some point over the last decade, it would seem, that open source morphed into the likeness of Rome’s ancient Colosseum, with competing projects and companies acting as gladiators in some sort of virtual arena. This has undoubtedly put a damper on what many of us in the open source ecosystem considered to be fun and exciting work. So, as with all things we find important, we should take inventory time and time again on our goals and direction.
We believe that great ideas can flourish through a virtuous democratic cycle that values transparency as a path to rapid innovation. This is why we believe in open source as a way to drive public participation in the art of framework building. As a small player, we’ve taken the risk of putting the source code to our best ideas out there, because we know you can help make it even better. That’s why we created XOOM.
By positioning ourselves as a competitor or contender to the industry heavyweights, we become forced to fit a mold that stifles innovation and limits creativity. XOOM is a set of libraries that provide differentiated capabilities for developers building JVM applications. Some of these features overlap with features offered by libraries like Spring or Akka. We realize this. We also realize that we cannot control the roadmaps and the development of those projects. Our answer to this has been so far to limit our dependencies on other projects while offering the most important capabilities for developers building distributed systems. Be this counter-intuitive in many scenarios—we wanted to see what would happen if we defied the popular saying: “Don’t build it yourself.”
Many open source tools are ultimately driven and influenced by the maintainers that are working to become profitable companies under an open source business model. Sometimes these tools are maintained by foundations. More rarely, we see tools driven by a slower and more visible community process where multiple companies influence a tool’s direction. Influences and agendas ultimately end up driving roadmaps for many open source projects, and that’s totally fine.
In very rare cases you will find an open source project is completely driven by the ambitions of a community that rallies around it. This is what we want for XOOM. To be successful in this mission we realize that it is important to provide a familiar way to evaluate and to contribute to each of the XOOM components.
We would be in good company to say that Spring Boot has become tremendously popular and useful to JVM-based application developers. The story is infamous—going back to 2002 when Rod Johnson and Juergen Hoeller forged the beginnings of what would become SpringSource. After the better half of a decade, in 2009, the reigns to SpringSource, and its open source holdings, were handed over to a company called VMware. From 2009 to 2013, many users of Spring Framework and Spring MVC started to face challenges with their software architectures. Large monoliths became uncomfortably heavy and resistant to change, which was not a problem caused by Spring, but more so a product of its conventions—specifically around configuration.
In 2013, Spring Boot was born as an opinionated JVM microframework that tied together the different components of the Spring libraries. Spring Boot’s distinction as a “JVM microframework” is an important one. Spring Boot realized that a majority of time spent in getting up and running with a Spring Framework application was due to configuration. By providing opinionated defaults to developers, they could simply pick the components for an application, and be returned with an auto-configured application based on finely-tuned production configuration profiles.
Indeed, the breadth of the Spring Framework libraries presented a lot of possibilities for developers … not unlike shopping for food without a recipe in mind. To be able to cook your own meals in a fast and repeatable way, you’ll need a recipe—in addition to pots, pans, utensils, a stove, an oven, a microwave … well you probably get the point. Alternatively, there are other options, namely, to either eat out or buy a pre-cooked meal—which all introduce tradeoffs in exchange for reducing the time spent cooking a proper meal.
At the end of the day, we see XOOM as a different and familiar alternative to other open source frameworks in the JVM ecosystem. More than anything, we see ourselves, the maintainers and contributors, as being positioned to contribute additional options to the open source ecosystem. By trying to reach feature parity with other JVM frameworks, we would find ourselves in a foot race that we never wanted to be in. However, we do believe that overlapping capabilities—ones that have become the norm—are necessary components. These capabilities must be included, should XOOM be considered a complete solution for building distributed systems on the JVM.
There will be times where XOOM contributors won’t have time to develop the competency, or the time to apply their already acquired competency, to build in certain, however necessary, capabilities. In these cases, we will contemplate relying on other libraries. We are not intentionally shying away from the benefits of including other open source libraries. However, we feel that it is good engineering practice to not couple our release cycles to dependencies we cannot directly influence. We believe that this has caused reduced momentum for other JVM frameworks. XOOM will always try to pursue the path of rapid innovation, for both the short term and the long term.
Having spoken to the uncomfortable atmosphere in which we have found ourselves, we hope you’ll join us in adding value in alternatives rather than subtracting from the possibilities. It is our hope that XOOM Turbo will help you realize our platform’s overarching goals of aggressive simplicity combined with lightweight fluency. While we are not the most mature option today, we hope to bring a breath of fresh air to a traditionally contentious space.
