This blog is part one of a three part series: Refactoring and Releasing the

new CC Chooser.

We’re excited to announce that we have finally moved the Chooser from a

long-term beta state into a finished and stable v1.0. But it certainly hasn’t

been a straight-line. The Chooser has been met with a lot of challenges along

the way and in this series we’ll walk through that journey in three parts:

Part 1: History and debt: The historical context that led to the newest

refactor and release of the 2025 Chooser.

Part 2: Specifics and fixes: Breaking down the specifics of technical debt,

issues, complexity, contextual-shift misalignment, and fixes.

Part 3: Future Growth: What’s next for the Chooser, and what directions we

hope to grow it.

What’s the Chooser?

From our website:

Our chooser helps you determine which Creative Commons License is

right for

you in a few easy steps. If you are new to Creative Commons, you may also want

to read licensing considerations before you get started with the

chooser

Circumstances and context

What do you do when an ecosystem shifts, not just with the number of engineers,

but also from the focal point of complexity built around a core product that no

longer exists at an org? You evaluate the context within which everything

exists and you reevaluate what works from there forward.

The Chooser has existed as a tool within the Creative Commons (CC) main website

for over fifteen years, and helped guide countless people through their choice

of sharing restraints and freedoms combined with which Legal Tool those

requirements are best aligned with. In 2019 the Chooser was met with a need to

refactor both its UX, and also its core technological approach. The CC

Technology team was focused hard on CC Search, which would later launch in the

Summer of 2019. CC Search was a rather complex application that required a more

robust and dynamic user interface. It was in every way much more of an app than

a website and so the team chose to build out the CC Search engine with Vue.js.

Like the rest of the JavaScript ecosystem, this meant some speed and

affordances in dev time with a trade off in larger code dependency and

complexity; given the size of their team and the ecosystem they were seeking to

build it was a solid and reasonable judgement call.

Building an ecosystem from a strong core product

After landing on Vue and setting to work to build out the search engine, it

became reasonable to also move as many other projects to the same ecosystem so

that updates overall could better operate as a supportive ecosystem. If other

websites and projects were moved to Vue, then they could share dependencies,

benefit from fixes and updates, and as the CC Search engine grew it could have

the delightful benefit of lifting up all the other projects along the way.

With a larger engineering team to manage the ecosystem it made a lot of sense

(Node is sprawling, and can be overkill in the wrong circumstances). It

decreased the complexity of managing a search engine, while adding some

complexity to smaller projects, with the balanced gain of spreading updates and

works across the whole a lot more cohesively. The end goal here was a

development environment that was much less siloed and more responsibility

consistent in how it approached dev work.

Vocabulary also entered the picture at this time. Its goal was to operate as a

design spec and implementation “rule system” for the Vue framework

implementation.

Shifting circumstances

In 2020, Covid shocked our society, disrupted giving, and brought staff

reductions to Creative Commons. Most of the Technology team was laid off. Work

was mostly suspended, some projects were sunset, and others were left with

minimal maintenance. Thankfully, CC Search was acquired and continued by

Automattic as [Openverse][openverse]. However, with its absence came a rather

large hole at

the center of a very large development wheel.

Without the CC Search engine, now all the smaller projects which had adopted

Vue would no longer receive the benefit of being attached to the larger

project’s progress. Instead a balkanization began to unfold. The flexibility

and scale that the Node ecosystem had offered when the CC Engine existed at the

organization no longer applied, and now Node in all its forms within all the

various projects were a liability instead of a strength.

Node is a fast moving system, and without a larger team it was difficult to

keep dependencies updated, tested, and secure. Projects began to drift away

from each other. Some projects still utilized Vue, others only halfway, and

others abandoned in-progress migrations to Vue, instead falling back to what

they had been doing before. The ecosystem fragmented and technical debt began

to accrue. Since Vue (and by proxy Node/NPM) moves so quickly–the debt

accrual was considerable.

The 2020 Chooser in limbo

The 2020 Chooser, left with minimal maintenance, was a beta version. It was

revamped and rebuilt to focus on the latest legal tools, offer a better UX, and

incorporate the Vocabulary design system. It was built from the ground up

entirely within Vue. And so the Chooser largely stayed, mired in beta due to an

ever increasing amount of technical debt. The rest of the world was moving from

Vue 2 to Vue 3, but there wasn't capacity at CC to update the Chooser.

By 2023, the Technology team had the capacity to begin reducing technical debt.

Later that year the main CC site redesign was launched. That work cleared the

way for redoing the Vocabulary design system, removing Vue, and simplifying its

approach to be better scaled to a more concise set of engineering resources.

The new site better utilized native WordPress functionality and minimized

JavaScript (it did not use Vue or any other JavaScript framework).

Laying groundwork for a refactor and release

A lot of time had passed since its original beta redesign and 2020 beta

release. The scope of the Chooser needed to be reconsidered. The core of its

functionality needed to be narrowed back down to manageable goals, decision

pathways, and stable long-term engineering.

In 2025, the Chooser was updated to better align with both the larger CC dev

ecosystem and the capacity of the Technology team. These changes have resulted

in a Chooser that is more integrated, balanced, stable, and viable long term.

Moving forward

In the next part of this series we’ll walk through the technical debt the

Chooser had accrued, and the specific improvements and changes that we’ve

implemented!