Balancing Profit and Principles: Building a Software Business Without Exploiting Open Source

Sat, 31 Aug 2024 23:37:00 -0600

I spend a lot of time thinking about where open source helps a software business — and where companies use the label while extracting more than they return. Building SpartanAuth has made that less abstract for me. I care about doing right by developers, and I also need a business that can sustain the work through Masonite Studios.

One quick boundary, because accuracy matters: SpartanAuth the service is not open source. What is open source is the login widget library, and I am proud of that. The rest of this post is about industry patterns I see, not a claim that my whole stack is OSS.

Service

Not open source — commercial product

Widget

Open source login library

In software, open source has been a powerful force for innovation and collaboration. As more companies embrace it, though, some adopt strategies that are profitable while undermining the spirit of the commons.

One common pattern is dual licensing with the AGPL (Affero General Public License). On the surface it can look community-friendly: a free OSS edition plus a paid proprietary license. In practice, some companies lean on AGPL’s legal ambiguity to push larger organizations toward the paid license, contribute little back, and treat “open source” mainly as marketing.

AGPL theater

When “open” is mostly a funnel into the paid license

If you want to build a software business without sliding into open-washing, there are better postures than “free core as a lead magnet you secretly hope enterprises are afraid to touch”:

True open source with support and services
Offer paid support, consulting, and custom development around software that is honestly open. This respects the community while funding the maintainers.
Open components, clear product boundary
Open the pieces developers need to inspect and embed (for me: the login widget), and be honest about what is a hosted/commercial product. Clarity beats pretending everything is free forever.
Community-driven work with sponsorship
Invite contributions and use sponsorship platforms so users who rely on the work can fund it directly.
Ethical productization
Pair strong engineering with values customers actually pay for — privacy, operational reliability, sane defaults — without bait-and-switch licensing.
Certification and compliance services
Help companies adopt the software effectively and legally through training, audits, or certification, without locking the ecosystem behind artificial scarcity.

5 postures

Ways to fund software without open-washing the commons

I do not pretend there is one pure model. I do think transparency beats theater. When a company says “open source,” I want to know what is open, what is paid, and who is obligated to whom.

Clarity > theater

Say what is open, what is paid, and who owes what to whom

For SpartanAuth, my current line is intentional: open widget library, commercial auth service I run for real apps (including several of my own), and this blog as the place I explain the tradeoffs in plain language. If that resonates, I would love for you to look at the product — and hold me to the standard of saying what is open and what is not.

Login Widget

Thu, 26 May 2022 23:24:13 -0600

When I started SpartanAuth, I had a simple obsession: authentication should be easy to do correctly. Complexity is where security bugs and abandoned sign-ins both hide. Today I want to talk about the login widget.

TLDR: usability, branding, and making the secure path the easy path.

Businesses lose real money when people cannot sign in. “About a third of online purchases are abandoned at checkout because consumers cannot remember their passwords,” from a study conducted jointly by MasterCard and the University of Oxford (source). That is a big reason I care about helping apps move away from relying on passwords.

~⅓

Of online purchases abandoned at checkout over forgotten passwords

MasterCard / University of Oxford

Replacing passwords with stronger authentication can be expensive, complicated, error-prone, and hard to use. SpartanAuth exposes an API so you can build your own login page — but I also wanted a complete path that is kind to both end users and the developers wiring it up.

User experience matters. So does branding. A login screen is often the front door of a product; it should feel like your app, not a generic detour.

So I built a login widget with the factors SpartanAuth supports, configurable enough to match your look and feel.

Choosing a tech

Shipping third-party UI into someone’s app is a trust exercise. I wanted the widget stack to be reliable, fast, and small. Frontend framework debates aside, the last decade of competition has been great for bundle size and performance — and I wanted those gains.

I set three criteria. The technology had to:

be simple to implement in any web environment
have a minimal bundle size when delivered to the end user
be a leader in performance

Simple

Drop into any web environment

Small

Minimal bundle for end users

Fast

Performance as a first-class goal

My first prototype was in Vue. Reactive UI is lovely, and the prototype was decent — but Vue is not ideal when you are shipping a single custom element. They even say explicitly that “it is not ideal to use Vue if you are shipping a single custom element”. So I kept looking.

At the suggestion of my friend Christopher Bradshaw, I found SolidJS. This blog post is still one of the clearest write-ups I have seen on compilers, bundle size, and performance. Reactive programming on top was icing.

Solid checked the boxes: near-vanilla JS performance, a bias toward less client JS, TypeScript support, and a tiny final bundle. And yes — it could ship as something developers drop in easily.

Solid has a library aimed at custom elements: Solid Element.

Results

The early Solid prototype was promising. A custom login page could look like this:

<script type="module" crossorigin src="/assets/index.2157afe0.js"></script>

and

<spartan-login start-mode="webAuthn" locale="en" redirect="/app.html"></spartan-login>

2 lines

To embed a full login experience

~17 KB

Gzipped bundle in the early Solid prototype

Bundle size was already reasonable, with room to improve:

index.668c492a.js            44.63 KiB / gzip: 16.70 KiB

That build included i18n, and the multi-locale result looked like this:

Four copies of the login widget each with a different language.

Customization started simple and powerful: pass CSS through a styles attribute and it applies. More knobs can come later; full CSS control is already a lot.

Login widget with the button stylized to match with a background of trees.

This matters to me: the login widget library is open source. You should be able to inspect what you embed. SpartanAuth the service is a product I am building and running for real apps — including several of my own — but I want the client piece developers drop into a page to be transparent.

Open widget

Inspect what you embed — the login library is open source

Next steps

The widget began as a focused prototype and grows as the backend gains features. If you want to follow along, use the RSS feed or the newsletter below. And if you are building something that needs auth, I would love for you to try SpartanAuth.

open-source on SpartanAuth Blog

Balancing Profit and Principles: Building a Software Business Without Exploiting Open Source

Login Widget

Why build a widget?

Choosing a tech

Results

Four copies of the login widget each with a different language.

Login widget with the button stylized to match with a background of trees.

Why the widget is open source

Next steps