Last week I walked through Fizzy, the latest product released by 37 Signals, and completely missed the fizzy-saas repo. I cracked open that repo and discovered references to the mysterious “Queen Bee” gem.
Watch the video and let’s dive in.
Fizzy SaaS
The first thing I noticed about the Fizzy SaaS repo is the gemspec that has all of these dependencies:
spec.add_dependency "rails", ">= 8.1.0.beta1"
spec.add_dependency "queenbee"
spec.add_dependency "rails_structured_logging"
spec.add_dependency "sentry-ruby"
spec.add_dependency "sentry-rails"
spec.add_dependency "yabeda"
spec.add_dependency "yabeda-actioncable"
spec.add_dependency "yabeda-activejob"
spec.add_dependency "yabeda-gc"
spec.add_dependency "yabeda-http_requests"
spec.add_dependency "yabeda-prometheus-mmap"
spec.add_dependency "yabeda-puma-plugin"
spec.add_dependency "yabeda-rails", ">= 0.10"
spec.add_dependency "prometheus-client-mmap", "~> 1.4.0"
spec.add_dependency "console1984"
spec.add_dependency "audits1984"
They’re all monitoring and auditing gems, which makes sense when deploying a Rails application to production. There wasn’t much else to the repo, just a signup flow and something that looks like a signup page.
What I’m still not clear about is why the main fizzy repo has a Gemfile.saas with similar dependencies. Here’s why the file is interesting:
gem "activeresource", require: "active_resource"
gem "queenbee", bc: "queenbee-plugin" # 🐝
gem "fizzy-saas", bc: "fizzy-saas"
See the queenbee and activeresource gems?
“Queen Bee”
I’m not exactly sure what the Queen Bee gem is, but I’m guessing it’s something used in the hosted SaaS version to check in with a centralized server about the standing of an account, the database of a customer’s data, the features they have enabled, and all the “stuff” needed to monitor and bill a customer for a SaaS product.
I know activeresource is a RESTful Rails client gem, so I wouldn’t be surprised if that’s being used by Fizzy instances to connect to “Queen Bee” to get this information.
What’s not entirely clear to me is how the data will be managed. Will each customer get their own database provisioned on MySQL? Or is there an accounts key in the Fizzy schema that will be used to keep track of different customer accounts in one database?
ONCE and self-hosted apps probably don’t make much money
My take on ONCE is that the model probably doesn’t really work that well in terms of generating revenue.
Do developers love it? Absolutely. They can play with the code, deploy it to any server. The problem is that most people who are not developers don’t want to host their own applications.
It seems 37 Signals is pursuing a hybrid model where developers can hack on the code, improve it, and run it on their own machines, and non-technical customers can pay for the hosted SaaS and never have to know the source code is available for anybody who wants to hack on it.
Challenges in hosted multi-tenant architecture
The ideal single tenant app in a repo like Fizzy wouldn’t have an accounts table or an Account model. Instead users would just be added to the application and each account would get its own database.
The Fizzy repo isn’t there yet. The default setup process requires running MySQL as a separate service, which I suspect is because they’ll have it connecting to each customer getting their own MySQL database.
There also appears to be an accounts table, which I’m seeing after making my video. Let’s pretend like it doesn’t for the sake of conversation, which is something I’m considering for a science fair Rails app I’ve been using for a few years at my kids’ school.
The challenge then becomes managing migrations across thousands of databases, which Rails tooling doesn’t really do all that well today. That said, I don’t think getting that working will be terribly difficult. It’s a matter of running migrations in two modes:
Run migrations in the background
When a deployment goes out to all Fizzy instances, something like “Queen Bee” could schedule database migration jobs per database. Those jobs get queued and over the course of a few hours or days, all the databases get migrated.
Run migrations when a user accesses their apps
If an app is running new code that isn’t compatible with the old database, a message could be displayed to the user, “Stand by while we migrate your database.” Since each database won’t be that big, this could conceivably run in a few seconds or minutes and the user would be on their way.
Öpen Source
Of course there’s a bit of a flame war going on about the definition of “Open Source”. This isn’t surprising; when source code is made available outside of the MIT or GPL flavored licenses there’s a flurry of people who send out the Open Source Initiative’s definition of Open Source.
My take? I think of “Open Source” as a marketing term and it means different things to different people. For example, there’s a debate that MIT isn’t truly Open Source because people who fork it and make changes can keep their derivatives private. GPL requires that those changes are made available. See where this is going? Within that narrower view, “Open Source” means very different things with radically different consequences for the licensee of that code.
What matters when evaluating whether or not something is “Open Source” is the actual text of their license. Fizzy’s is a derivation of the MIT license with an additional clause.
# O'Saasy License Agreement
Copyright © 2025, 37signals LLC.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
"Software"), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
1. The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.
2. No licensee or downstream recipient may use the Software (including
any modified or derivative versions) to directly compete with the
original Licensor by offering it to third parties as a hosted,
managed, or Software-as-a-Service (SaaS) product or cloud service
where the primary value of the service is the functionality of the
Software itself.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Does this violate the OSI’s definition? Yeah, definitely this part:
The license shall not restrict any party from selling or giving away the
software as a component of an aggregate software distribution containing
programs from several different sources. The license shall not require a
royalty or other fee for such sale.
Here’s the thing, though: to my knowledge, OSI doesn’t own the copyright to the word “Open Source”, so at the end of the day people are free to use it as they see fit.
It’s analogous to how food manufacturers can slap the word “Gourmet” on their label. I’ve seen hotel lobby coffee labeled “Gourmet Coffee”, I tasted it, and it definitely wasn’t gourmet. Some people will find it in poor taste, most people won’t care.
“Real” Open Source has problems too
Minio, a self-hosted S3 clone, is the most recent infamous example of an OSS license going sideways. It started as an open-source project, then they commercialized it and functionally killed their OSS project by closing new source contributions.
Trust & damage control
When I evaluate a software library or project, the big question on my mind is “trust” and “damage control”. For example, if I see a project that’s MIT licensed, created by people or a community I trust, that I know I could replace easily in my project, it’s a no-brainer that I’d pull it off the shelf and start using it.
For me, part of building that trust is being as upfront as possible about intentions.
In the case of 37 Signals, their license makes their intentions clear that you can do whatever you want with their source as long as you don’t compete against them. I’m not currying favor with 37 Signals, but I vastly prefer this approach to the “Good vibes OSS” for a few years until the project becomes a commercial success, then pulling access to the source code, forcing people to pay up or work with old code.
Source Available? Öpen Source?
When the OSI proponents throw the Open Source definition around, they like to tell people to instead use the word “Source Available”. I don’t think this distinction really helps that much because again, there are huge differences between GPL, MIT, and other “Open Source” licenses. What matters is what’s in the actual text of the license.
Maybe just for fun the No True Open Source projects instead change their “Open Source” designation to “Öpen Source”?