Thread by @imakefoss

Today in @Akien's ramblings:

How to make a #FOSS project successful?

(Or more truthfully, some factors of @godotengine's success story, and what are key takeaways to reproduce it?)

A thread ⬇️

@Akien My focus here will be quite specific to non-profit, non-corporate #FOSS projects.

#FOSS projects run by companies, with their own employees paid to write and maintain open source code, have their own dynamics which I won't cover here into detail.

@Akien With @reduzio (creator of @godotengine), we often get asked about the secret recipe for #FOSS success.

Godot was released as a rough, niche engine in 2014, and grew exponentially with ever more users, contributors, and now paid devs, to go rival proprietary alternatives.

@Akien IMO, it did three things right from the start:

1. Functional product from the start, with a simple design.
2. Fully free, permissive license (MIT). No strings attached.
3. Fully embraced the #FOSS philosophy (and #indiedev for the #gamedev world).

I'll develop each point below.

@Akien Godot started as a proprietary in-house engine developed by @reduzio and Ariel Manzur, and used for their own games.

At that time general purpose game engine were not so common and expensive to license, so Juan and Ariel worked as consultants using their own tech for each game.

@Akien They worked with teams of artists, designers, gameplay programmers, etc., and their job as engine developers was to put the game together.

To avoid being bottlenecks for other team members, they built tools to let them all do the integration themselves.

@Akien Game development is a very iterative process. You often make things, test them in the game, redo them, test again, etc., until it all feels "right".

Having to wait for an engine programmer to test each iteration is a big bottleneck. So Godot was created to enable this iteration.

@Akien That's quite important as it means that Godot was born of the real needs of actual game developers, and not just a "great design idea" from two programmers.

It was built as-needed for these games, implementing the new tools that they need, and evolving based on users' feedback.

@Akien So to me that's one key takeaway here: a successful #FOSS project must fulfill an actual need, and do it well.

Many projects start on idealized concepts of "modern code" or "good architecture", and they're great to develop new skills, but they often lack practice use cases.

@Akien In 2014, @reduzio and Ariel decided to opensource Godot under the MIT license.

The #gamedev world had changed a lot with the rise of affordable and user-friendly game engines, albeit proprietary.

They both loved & used #FOSS and had been thinking about releasing it for a while.

@Akien This was a very mature product from the start, and the reception was great from people both interested in #gamedev and #FOSS.

godotengine.org/article/first-…

Of course, like most in-house engines, Godot was pretty rough. When the engine is for one team, you don't invest so much on UX.

@Akien But #FOSS people tend to be more forgiving, as we've all done efforts to use FOSS tools with arguably worse UX than proprietary tools, *because* they were FOSS.

Thankfully, UX in FOSS has improved a ton and these tools have now grown to be among the very best (e.g. Blender).

@Akien Juan and Ariel were maintaining Godot as a hobby project, and dozens of #FOSS hobbyist game developers started contributing fixes and new features, improving cross-platform support and UX.

The first public release, Godot 1.0, was published in Dec 2014: godotengine.org/article/godot-…

@Akien Look at this cutie :3

Godot has changed *a ton* since then, yet you can still see many similarities in the overall design of the interface (and of the API, if you were to use it).

@Akien For the comparison, here's the number of lines of code in Godot on its first open source commit, and today:

2014: 730,000 lines of code (and a lot of it was unused and ended up removed little by little as we cleaned the codebase).

2020: 1,900,000 lines of code (all of it used).

@Akien Godot was far from competing with big commercial engines in 2014, but it had potential, and was the most serious #FOSS option to contribute to.

Users really liked the way it was designed, finding it very intuitive and easy to use.

That was a great start, and it kept growing.

@Akien Alright, now back to:

2. Fully free, permissive license (MIT). No strings attached.

That one is simple: #FOSS is based on trust.
Trust is based on fairness and reciprocity.

@Akien These days, we see a lot of commercial products that start understanding the value of #opensource for their product, but not its fundamental values.

So they open their source code (great!), but often with custom, needlessly restrictive licenses.

@Akien These custom licenses are not #opensource, and do not establish a relationship of trust between users (who can be contributors too) and the developer or company behind the product.

But if you want to benefit from the momentum of the #FOSS community, you have to go all in.

@Akien Whoever started the project should not be able to change the license to a more restrictive one, or completely remove our right to use, modify or redistribute the project.

That's the risk with projects having a Contributor License Agreement (CLA) which often enables this.

@Akien Perhaps even more importantly: if I'm to contribute my work for free to a project, I don't want the project owner to benefit from it more than I or other users could.

I don't want to work on others' product for free, I want to work on the #commons.
en.wikipedia.org/wiki/Commons

@Akien Godot established this trust from the start by using the very permissive MIT license, and by not using a CLA.

It means that Godot is owned by all the contributors who worked on it over the years. We each own a part of Godot's copyright which we contributed to it.

@Akien So we can never change the license terms of Godot, unless we get the approval of 1,200 contributors!

What is available now will always be available. We could decide to change the license for future changes, but anyone can fork the current code and keep developing it.

@Akien But even that is not enough - say we were a big company hiring most contributors, and we decide to change the license for future code to proprietary.

You can make a fork, but if the bulk of the development team focuses on the proprietary version, you'll lose a lot of momentum.

@Akien That's why Juan and Ariel made Godot join @conservancy, a non-profit organization that focuses on supporting and promoting #FOSS.

Their mission statement is that everything we do must be #FOSS and in the benefit of the project.
We simply *can't* fail you.
godotengine.org/article/godot-…

@Akien So Godot is a game engine which is developed by and for its users, and owned by all its contributors and a non-profit charitable organization.

It's yours to use, modify, fork, redistribute, even sell if you want. Today, in a year or in three decades.

@Akien BTW, this perspective of a random company taking your project, rebranding it and selling it, is a fear that many seem to have when open sourcing (leading to sad "nearly open source but no" situations like defold.com/license/).

@Akien But think about it: who would buy a commercial fork if you have a thriving community making the best free engine out there?

Would you buy a proprietary fork of Blender maintained by a lone developer, that would become outdated in less than 6 months?

@Akien In non-profit #FOSS, you best security against undue competition is to give your users the very best value.

And nothing is better than unrestricted use and a thriving community of dozens, hundreds or thousands of dedicated contributors.

@Akien Last but not least:

3. Fully embraced the #FOSS philosophy (and #indiedev for the #gamedev world).

I partly covered the former in (2), but I'll explain some more.

@Akien In #FOSS projects, legal terms (license) and power structure (CLA, ownership) is indeed very important, but there's more:

The perception the community has of your motivations. And of course, your real motivations (usually, it will be the same, communities are clever things :)).

@Akien If you're "openwashing" and using #FOSS as a way to make your project popular and benefit from contributions, without fully committing to it, you might not be trusted.

People will naturally start by being suspicious of your motivations as a person, or worse, as a company.

@Akien Again, I'm not talking about corporate or commercial #FOSS here, and I'm not saying that those are wrong.

But the community needs to understand *your* story if you want them to support you.

That requires one thing: transparency.

@Akien Be clear about your motivations. If you have funding, be transparent about it, and tell the community how you use it.

Your project governance doesn't have to be a democracy, but it should be transparent and you should communicate your vision and decisions to the community.

@Akien At least in the beginning, Godot's users were almost exclusively using it because they made #FOSS their priority.

Nowadays, Godot's growth and maturity means that most users use it for its own merits as a game engine, and not just due to its license terms.

@Akien But those early days of strong support by #FOSS aficionados (which hasn't reduced in any case, it just decreased in proportion) were crucial to Godot's development and success.

And #FOSS "fans" are often very emotionally attached to their project, and to its contributors.

@Akien So you have to be trustworthy and likeable. If people don't like you, they won't bother support your still-wonky #FOSS projects to let it reach a high level of maturity.

That's where we tie in with #indiedev, aka indie game development, which often relies similarly on affect.

@Akien If you set to make a commercial indie game in today's heavily congested market, you can't count on your own proficiency alone.

You might make the best game ever, but if nobody finds it, it will have any success.

So one of the keys to #indiedev is to build your own community.

@Akien Just like in #FOSS, you need to reach people who will have a personal interest in your project and to some extent your person.

If you find people who like what you do, and like who you are, they will *want* you to succeed. They will do their best to promote your game.

@Akien Godot had this chance to be at the intersection of the passionate #FOSS movement and the expanding #indiedev world.

Many Godot users want the project to succeed and to keep growing, as they have a personal interest in it, and often an emotional attachment to it.

@Akien I'm not sure what my key takeaway is here aside from:

Be likeable.
Make your project likeable.
Ensure that you have a likeable community.

And of course, be genuine about it. It's not being nice to profit from it, but actually working towards the best interest of your users.

@Akien And perhaps even more importantly, aside from having a successful project, you'll have a great time.

There's no better feeling than to work for the benefit of your community, with no ulterior motive than to provide the best technology possible for the common good.

@Akien And yes, this might sound idealistic or cheesy (or worse, socialist 😱), but that's what we actually do in Godot.

And we're having a blast 🔥

Have a nice week-end!