Open Source is the Way
It's both beneficial and problematic to develop something in the open. Do it anyway! I'm trying to, with this web game project.
People can debate different approaches to software development, going around in circles endlessly. Rather than losing breath on discussions, it's better to just do the hard work of development and make something tangible. Fail faster, fail sooner, and iterate until you arrive at something good enough. Let actions speak clearly.
That said, I like open and transparent development. There's a huge host of problems, and a mix of benefits. As with all things, the answer to "which is better" is just "it depends."
My philosophical stance is that openness is the way; that transparency and clarity are virtues.
Truly, it's both beneficial and problematic to develop something in the open. Do it anyway! I'm trying to, with this web game project.
Blasphemess is influenced heavily by my lifetime of Linux and open source experience. From my first experiences onward, I learned that ideas should be free, and that open collaboration is what creates wondrous projects.
At the moment, I'm just a solo developer. The open source way guidebook is a handy reference for a lot of the things I believe in (more on that later). Core to that is that I'm giving away my competency for "free" to make my idea into a reality. My efforts will eventually foster a community around this game, making a community of people who similarly find value in playing. Those people may enrich the community further in a variety of ways.
It's as I said in a prior post: I can do any parts of this project, but if I want to go fast? Then I don't want to do all of it alone. I'll need help.
Which is why this blog exists, to talk openly about the development process so that others better understand the way of things.
A project is more than it's source code, after all. It's about people, their collaboration, the users, and more! There are all sorts of soft skills, intangibles, and trust involved. The first step to building trust and finding collaborators is communicating.
For me, I'm most interested in making this game last. Perhaps I even want it to outlive my contributions, and become an independent entity.
What I definitely don't want is to go down the path of enshittification and platform decay, or anything similar. Thus, I want to avoid monied interests in what is largely a passion project of software and art.
The Royal We and Solo Dev Projects
There's a fantastic article by one of the founders behind Plausible Analytics (the inspiringly successful open source project), about hiding behind the bland and royal 'we.'
Uku Taht
"When you make communication personal, customers are much more likely to talk to you"
That's not to say that every project should take an individual approach. Rather, it's an advantage for tiny teams or solo developers to "do the things that don't scale" early on and not mask themselves behind generic entities.
There are a lot of good points in the article, including that impression royal-we developers may accidentally give of being bigger than they are. People can expect big company incidentals from volunteers and solo devs, if the 'royal we' is misinterpreted.
My take-away is to be up front about who I am: a solo dev, with more talents than time. I'm passionate and ambitious, but there's always that threat of the bus factor looming over me.
Starving Open Source Artists and the Inescapable Problem of Economics
There's a pretty big problem with open source projects. Let's call it the starving artist problem:
How do I justify the economics of labouring on Blasphemess?
It's a steep initial investment of time, and several modest ongoing costs for operations in time, money, and liability/risk. Passion can get me to take on a project, but passion doesn't keep the lights on and the contributors fed.
There's many creative people that would love to contribute to open source projects – if they had the time and freedom from bills to work on it. Open source projects have a reputation of being inaccessible in this way. It's the realm of the wealthy or privileged or self-sacrificing.
To justify my work, do I then say that I should just accept the opportunity cost of game dev for free? Or do I try to monetise the game in some way, going contrary to some of my morals and beliefs?
There's also a common story for projects: the solo-dev who has 'life happen,' and then abandons the project because they can't keep up with it any longer. Such abandonware is a real stereotype in open source ecosystems, since software goes stale without maintenance, bug fixes, and feature improvements to fit the shifting needs of the users.
In some cases, orphaned or abandoned projects may be taken up by users in the community to maintain it. Yet if a community has not yet been developed, as is often the case with newer projects, then it's likely doomed.
Well, thankfully, I'm not the first person to think over this problem. Enter this humbly titled talk on economics, open source projects, and more:
There's too much in the video to summarise succinctly, so I recommend watching it if you're interested in the non-technical aspects of software projects. What I will say is this:
Profit is not evil; the love of profit is. Profit is necessary for self-sustaining and growth, barring exceptional cases like patronage.
Now that we have a basic understanding of the problem, let's look at the solutions in the sustainable open source space.
Sustainable Open Source
I love Ghost, the blog software. It's how I run this blog, and I especially love the open-source and perpetual non-profit commitment they made.
On their about page, they have this impactful statement:
The more people who use Ghost, the more customers we have, the more revenue we receive, the more great people we can hire to work for the foundation, the better the software gets, the more people use Ghost… and so on.
It's a virtuous cycle which means that we can keep creating open, adaptable software with a vibrant future, forever.
There's no venture capital pushing quick returns, and there's no public investors demanding quarterly profit increases. There's simply the focus on creating true value for the users, and winning market share slowly and diligently.
I love to see successes like this!
The Ghost organization is using a Software-as-a-Service (SaaS) model of business. They offer their software (the Ghost blog) for free, with the source completely open. However, running a blog on your own has costs in terms of time, skills, and attention. For those people who don't want to do it themselves, they can pay for Ghost Pro to manage their blog's operations for them. Ghost Pro offers a service to users for a subscription fee.
There's a collection on wikipedia of different business models that open-source software can relate to. Notable options include:
- Software-as-a-Service (like Ghost)
- Open-Core, Dual-Licensing (like Gitlab community vs. Gitlab enterprise) and Freemium (where there's a free tier but also content that can be bought, like in Fallen London)
- Donationware (funded by donations from some users)
Each of these three options come with tradeoffs. Open-core software, for instance, often arbitrarily limits what users can do unless they purchase the fully-featured software. Donationware can be wildly inconsistent, and generally leads to the aforementioned starving open source artists.
Of the three, software-as-a-service intrigues me as an option for sustainable growth over time. It's as Ghost puts it; with enough time, the growth will snowball and create something great for the users.
All too often in the tech industry I work in, I see capital pushing for unsustainable growth. People love to focus on exponential growth, huge-scale products, mass adoption, and extracting wealth from lots of users.
Small open source projects don't have the luxury of lots of capital to fund their growth. They have to be intentional and slower about their development. They have to stay sustainable to last, and to not burn out their contributors.
Enter the Open Source Way Guidebook 2.0. The guidebook was mentioned in the talk on the economics of programming languages, and condenses many observations I concur with into a dense book.
I love this quote from the opening:
...it is easier to teach skills than to teach someone to truly care about your project.
People who care make up the liveliness to the project. People who care will offer their thoughts and feedback, be patient with slow solo development cycles, and will return creativity for creativity.
The guidebook lays out three stages of a pipeline, with which I might sustainably grow a thriving project: attract users, guide participants, and grow contributors.
The first, attracting users, is the most obvious: if I'm writing code, I want people to use it. Unused code is worse than having not written it at all. To win users for a game like Blasphemess, players are largely of an unfilled niche internet gaming approach. The value proposition is that for minutes at several points a day, players can engage creatively like they might with a large scale tabletop RPG.
Guiding participants is more nuanced. Sure, you have people who are wholly "users" and people who are "contributors," but what about in the middle? What about the users who spread word of the game, or who report bugs, or complain about imbalances, or daydream of interesting mechanics?
Enthusiastic participants will help propel any project forward, and with a little guidance, their energy can be directed to useful ventures.
From the group of participants, contributors will often emerge. Not just be fate or chance; often times they will be mentored, encouraged, and supported. That's what growing contributors is about.
In the long run, any healthy project needs a constant influx of new energy and people, to prevent maintainer burnout. Contributors need room to take vacations, without stalling out development and operations.
This pipeline aligns well with my goals: I've developed plenty of professional polish and glue work skills in my professional life. It's something I wish to share with other enthusiasts, to help develop their skills.
I see this game project as a wonderful opportunity for people to transform a passion for a game into enjoying contriutions and developing skills in coding and game design and more.
Business Ideas for the Future of Blasphemess
Returning to the earlier point: sustaining a project requires profit. How to do so, and how much is needed, is a wildly open question. For the time being, I'm fine with donating my resources to my circle of friends.
That won't hold as true as the project grows.
I have no idea how big a phenomenon I want this game to be. How many active users will be the sweet spot? Fifteen? Fifty? Two hundred? A thousand? Ten thousand?
Each niche could be interesting and different! There's a different class of problems to tackle with each amount, and different ways to make things interesting.
For instance, scaling the game to 10k or more players is a challenge that horizontal sharding can help with. At the two hundred players point, then moderation tools will be a major factor. At the fifteen players point, running lots of personalised in-game events is one way to engage them, like you'd find in a tabletop game.
I have countless ideas bouncing around, and only time will validate what works great – or not so well.
Yet one that sticks in mind right now is adopting the Ghost SaaS model: to offer private hosted Blasphemess clusters for a group of players to have a personalised game experience.
I envision someone taking on the role of story teller, buying a hosted cluster, and developing a map and setting for their players to engage in privately. Rather like a classic TTRPG, but virtual and largely played asynchronously.
There could be self-hosted options to go along with the SaaS hosting, since I'm a huge believer in running your own services when you have the ability to do so.
Getting There From Here
Having direction is important to developing this game. I know I want to have open-source self-hosted clusters in the long term. In the near term, I just need to write enough code to get a prototype/alpha off the ground and running.
Somewhere along the way there will be an inflection point, where I swap from being a solo-dev project with closed source to something open.
Until I have something prototyped, though, no one is going to care enough to help. That's the nature of projects, few people are going to buy into an idea alone.
After all, ideas are cheap. It's execution that differentiates success.
