Why Fullstaq Ruby

A while ago, we at Fullstaq started the Fullstaq Ruby project: a Ruby distribution that’s optimized for server use cases. Compared to normal MRI Ruby, Fullstaq Ruby uses 50% less memory, is faster, and is easier to install and security-patch because of RPM and DEB packages.

Since I announced Fullstaq Ruby on EuRuKo 2019, I have received many questions about Fullstaq Ruby’s vision, purpose, and nature:

• Is Fullstaq Ruby a commercial product, or are there such plans?
• How will Fullstaq Ruby stay maintained?
• Who is in control of Fullstaq Ruby?
• Why are the changes in Fullstaq Ruby not in upstream Ruby? What is the current, and envisioned, relationship between the Ruby core developers and Fullstaq Ruby?

In other words, people are wondering: “how do I know this is, and stays, a real thing that I can count on?”

These are legit questions! As the author of Passenger and Ruby Enterprise Edition, I’ve experienced first-hand what the challenges are of building a healthy open source project. In this post, I will describe my vision on this matter.

Fullstaq Ruby is Open Source

Fullstaq is entirely open source in the fullest sense. It’s not just open source in the sense of “here’s a code dump”. No, we’re really committed to go the last mile. We envision these that anybody should be able to:

• understand how Fullstaq Ruby works.
• contribute to Fullstaq Ruby.
• fork Fullstaq Ruby.
• benefit from Fullstaq Ruby’s work, without being locked-in to it.
• have a say in its future direction.

We want to achieve this through several pillars.

• The first pillar is automating everything, and open sourcing that automation. All organizational processes are to be stored as code, and the code is the canonical sense of truth. There should be as few manual processes as possible.One should be able to understand everything about how the project works, by reading the code. One should be able to contribute to any part of the project, by modifying code.With the introduction of a CI/CD system not long ago, this pillar has mostly been reached.
• The second pillar is documenting everything. Having code is nice, but code alone does not always allow understanding. Code is not always easy to read and may not convey enough high-level information. The code should be accompanied with documentation that explains concepts, architecture and processes. There should be no undocumented processes, i.e. processes that live in a few individuals’ heads.With the proper documentation, we want to promote understanding, and to make it easy to contribute. If one runs into an issue, we want to make it easy to debug and resolve that issue by having the proper documentation. If it’s easy for anyone to resolve an issue, then that eliminates vendor lock-in.
• The third pillar is reproducibility. Setting up a software system can be very complex, with lots of dependencies to install and lots of configuration to manage. Furthermore, and increasing amount of software nowadays rely on supporting cloud infrastructure: SaaSes, build servers and CI/CD pipelines. To fork a project, more than just code and documentation is necessary.We tackle these issues by automating as much as possible through the use of Docker. This should allow anyone to work on Fullstaq Ruby with a minimal amount of setup.We also tackle these issues by making the infrastructure reproducible. We encode as much infrastructure as possible using Terraform and Kubernetes. This should allow anyone to understand how our infrastructure works, as well as to fork our infrastructure and run it on their favorite cloud provider with minimal hassle.
• The fourth pillar is working in public. Development and discussions happen in public places such as Github.

You can see these pillars in action through the fact that the build system, website, roadmap, and infrastructure are all open source and available on Github. We welcome discussions and pull requests.

But note that we’re not there yet. For example there isn’t a lot of contributor documentation yet. Check out our roadmap to track our progress.

Fullstaq is All About Community

Even though we are the founders of this project, we do not intend on being the only developers of Fullstaq Ruby. From the beginning, we intend for Fullstaq Ruby to be a community project.

We will soon be recruiting core maintainers from the community. Right now we are working on establishing a good organizational structure, by ensuring that the proper automation, documentation and processes are in place.

With a proper environment that allows anyone to contribute and to join as a core maintainer, we increase the likelihood that the Fullstaq Ruby project stays healthy.

Fullstaq Ruby is Not Commercial

There are no monetization plans. There will be no paid version.

Fullstaq’s main business model is consultancy, training and managed services in the area of cloud native technologies and DevOps. Their mission is to help startups and SMBs to succeed in the cloud native way of working, which is why we are sponsoring this project.

How Fullstaq Ruby Stays Viable

We’ve all seen it: some gem you use becomes unmaintained, and now you have to wonder what to do with that. Nobody’s waiting for such a scenario, no matter how easy it is to fork the project and to take over maintenance.

So while some people see the lack of monetization of Fullstaq Ruby as a good thing, others are worried: without monetization plans, how will Fullstaq Ruby stay viable?

The answer is two-fold:

1. Automation. With sufficient automation (and sufficiently robust automation and infrastructure), a project will keep working for quite a while even if its maintainers become less active.
2. Community, as explained above. With sufficient maintainers from the community (and sufficient continuous recruitment), the project stays viable even if the founders become less active.

Fullstaq Ruby and the Ruby Core Developers

Some people wonder why the improvements in Fullstaq Ruby are not in upstream Ruby. The answer is because Fullstaq Ruby’s improvements are opinionated and specialized.

Fullstaq Ruby’s memory allocation changes are optimized for server use cases, but these optimizations are probably not suitable for non-server use cases, such as embedded systems and automation frameworks. Some of these optimizations require invasive platform-specific changes in the Ruby codebase.

Some optimizations are not even fully understood: for example Jemalloc 3 yields memory savings but Jemalloc 5 does not. The cause is still unknown; I hope to research this further in the future.

At EuRuKo 2019, I spoke with Ruby’s creator as well as a Ruby core developer, namely Yukihiro Matsumoto and Yuske Endoh. Matsumoto told me that, as the author of a language, he should take care of all of his users. This is one the reasons why the Ruby core team is hesitant to integrate Jemalloc. The other reason is because (as mentioned above) Jemalloc’s operation is not fully understood.

I have a lot of respect for Matsumoto’s position. Having said that, the server use case is an important one. Plus, one does not have to fully understand a phenomenon in order to benefit from it. For example scientists still don’t know why a bike does not fall over when moving. The benefits are so clear, I want as many server users to be able to benefit as possible.

There is also the aspect of security patching. Currently the Ruby core team does not provide any binaries, only sources. In this day and age, fewer and fewer people are comfortable with compiling software. Linux distributions always lag behind the source releases. I think there is a need for Ruby binary packages that are always up-to-date with the source releases.

But packaging is a whole different discipline, very distinct from developing a programming language. It is a very different kind of work from the work that the Ruby core developers currently do.

Towards a brighter future

How might we solve all of the issues described in the previous section? I think that that opinionated and specialized concerns do not have to be taken care of by the Ruby core team. There’s nothing wrong with such concerns being taken care of by a separate project. The only dangers are:

1. The separate project lacking mindshare because of lack of official blessings.
2. The separate project running out of steam (e.g. falling behind with official Ruby releases), due to insufficient number of contributors.

So clearly, for a separate project to succeed, it should work closely with the Ruby core team. There should also be a degree of official blessing.

Ubuntu Flavors might be a good example of such a concept in action. Ubuntu is based in the GNOME desktop environment, but there are separate projects (flavors) that use KDE (Kubuntu) and XFCE (Xubuntu) as the desktop environment.

So my vision is that Fullstaq Ruby becomes an officially blessed external project, whose mission is to take care of optimizations for server use cases. Matsumoto has shown interest in this idea. When Fullstaq Ruby becomes a bit more mature (organization-wise) I will talk to Matsumoto again about implementing this concept.

Please send me a tweet or an email and let me know what you think.