Weaving Into Open Source

One of the masterpieces of our era is GitHub. One of the greatest inventions of humanity is open source software. It is the reason we have the technology we have today. People can contribute to something larger than they could build alone. Others can take what's been built and bend it to what they need. We took Godot and bent it to what we needed, because it was open source. Open source also happens to be one of the best learning environments humans have ever built. People enter a community of creators. They build alongside, learn from, and get feedback from people far ahead of them and far behind them. The process of contributing to an open source product is the path to scalable practice-based learning.

We had one pillar of learning theory working: that building games is an excellent vehicle for teaching digital skills. Our programs proved it everywhere we ran them. Teachers loved it. Students loved it. The problem was scale. The team was being run ragged. The idea of 10x'ing the number of students, let alone 100x'ing or 10,000x'ing, was impossible.

We needed the second pillar: lots of people working together, on tiny creations and large professional projects alike, creating many opportunities for learning. Peers teach peers. Mentors can support far larger numbers of students when everyone is working on a common project. It scales non-linearly. It gets better with more people. When Endless is a community, that community can support students on a life-long learning journey, well beyond any time-bound program we run.

Where does open source software get built? GitHub. But GitHub is complicated. We couldn’t drop a learner into a repository and expect them to commit code. We had to build a ladder. From the earliest moment, they could grasp the concept of contributing a small piece of something larger until one day they could be in the repository contributing code.

To build that pathway, we had to build a game.

Our foundation team at the time was largely born from Endless OS. Open source software engineers, with a learning team alongside. None of them had ever built a professional game. If we were going to teach young people to build games, and to contribute to projects larger than they could build on their own, we had to build one ourselves.

I am still not sure exactly what happened. Maybe it was the creative energy of the learning lead. Maybe it was the game idea he brought to the fore. Maybe it was the team seeing how learning would wrap around such a game. Whatever it was, something clicked. The team understood:

We are now a game studio.

And wow did they build.

The game unfurled. A game about the power of story, set in a land of textiles. The fabric of the world is unraveling because the stories of its people have been forgotten. The players become StoryWeaver, whose job is to fight back memory loss and a lack of imagination, battle Ink-Drinkers, StoryVores and Woeverns, find the scrolls of stories lost, and return them to the Eternal Loom in Fray’s End, to be woven back into the tapestry of civilization. The art is lovely. A beautiful world of fabric flora and felten fauna. Soft to the touch.

And most importantly, it is an invitation to the students of the world: we need your stories.

This was Threadbare.

The learning team wrapped their learning programs around a journey through this game. Students from anywhere can contribute Story Quests, their own creations that reflect the cultures of their people. The code is open. Students can also contribute to the core game. Early in one’s journey, that means small things. A student can contribute animated flowers. Another took someone else’s static cat and animated it to life. As creators advance, they move into Lore Quests, the backbone quests that add core mechanics that other students will use throughout their own Story Quests.

The most advanced students in our college programs started tackling the core feature list. We needed a Quest Book. One student drew it by hand. Another coded the menus within. Another labored over the perfect animation for the paper to fold as the pages turn.

The game began to take on a life of its own.

Our engineering team then built scaffolding. Push a change to GitHub, and the game updates automatically. Templates with first-task lists populate with a click. Those tasks are mirrored in GitHub and our website. Students earn XP for contributions. XP becomes badges. Badges become microcertificates, in partnership with ASU.

A student now moves along a single, continuous path. They play Threadbare. They make a micro-contribution. They build their own Threadbare level. They contribute those levels to the live game. Eventually, they contribute directly to the core open source repository.

At that point, something fundamental has changed. Yes, they are still building a game. But it is no longer about learning to make games. They are ready to contribute to other student-built games from around the world. Or build their own, and invite others in. They have learned how to participate in large-scale, collaborative, professional projects.

Threadbare isn't finished. It was never meant to be. That’s precisely the point. The loom is open now, and students are weaving.