Rémi Verschelde

Godot Engine project manager and Mageia Linux developer

[July '20]

Rémi makes FOSS and takes our Twitter mic from July 22 to 29. Merci beaucoup, Rémi!

Tell us about yourself

I’m a French guy living in Copenhagen, Denmark, with a strong interest in Free Software (surprise!) and video games (especially indie and open source games). I’m incredibly lucky as I can reconcile these two passions in my day job as Project Manager for Godot Engine. Aside from talking with computers, I also enjoy learning natural languages and see how they shape and are shaped by cultures and history. I like hiking, bouldering, and cooking though I’m terrible at coming up with ideas of new dishes to make (suggestions welcome, veggie preferred :)).

What are you working on right now?

I work full-time as Project Manager for Godot Engine, which is the largest FOSS game engine project today with over a thousand contributors. My daily routine encompasses a wide range of tasks such as: triaging issues, reviewing and merging Pull Requests (i.e. code or documentation contributions), maintaining the stable branches and releasing new versions, ensuring the quality of the development branch in preparation for our next milestones, managing all the online communities of the project, handling the project communication and public relations, writing documentation, developing and maintaining our tools and infrastructure, debugging issues and writing some fixes, securing funding to hire core contributors – ok, I’ll stop boring you :)

We’re a big project with a thriving community of several hundred thousand users, yet 100% non-profit and thereby with limited financial means, so we only have a handful of full-time developers to support the project’s frenetic development pace (2 full-time and 3 part-time now, but we plan to hire a couple more). But even having some paid developers in the support of a fully FOSS engine was something I would never have dreamed of only a few years back, so we’re in a great position. And we keep growing at a good pace in user base, contributions, and funding.

What is most interesting about that?

The game industry has always been slow to adopt the modern trends of the general software industry, and this is especially true with its FOSS adoption. With a few exceptions (e.g. the id Tech engines for older Doom and Quake games), game studios have for decades developed their own in-house technologies without sharing any code. General-purpose game engines have then appeared and democratized the access to game development tools, but they were proprietary and closed source (with exceptions like Unreal Engine 4, which is proprietary but with source available, which is a huge advantage for its users).

While there have been various attempts at developing similar technology as FOSS projects, Godot is the first one to have really achieved critical mass and gathered a community so big that it is imposing itself as one of the major options in the game developer’s toolbox. Games are highly optimized software that needs to run expensive CPU and GPU computations at a stable 60 frames per second (that’s a max of 16.67 ms to compute each frame, with game logic, physics and rendering!), so having access to the source code of the tools and engine you’re using is a must have for any complex project, as you will always need to tweak some things to match your game’s highly specific needs. FOSS engines like Godot give you this possibility to make it your own in-house technology by developing the features and workarounds that you need – yet you can also contribute changes upstream and have them maintained by the community for all future versions.

How did you first discover FOSS?

As far as I remember, I was introduced to free software by my elder brothers in the early 2000s, when I was maybe 10-11 years old. The Mozilla suite, OpenOffice.org, early VLC versions… I once saw a Knoppix Linux system booted from a LiveCD, where you could even play some FOSS games, and was amazed by this new software ecosystem where everything was free, open and ethical. I started dual-booting Windows XP with Mandriva Linux 2005 LE (the first one to be rebranded from Mandrake 10.2 to Mandriva) and I enjoyed browsing the package manager of the Mandriva Control Center – all this software that I could install in one click felt magical (and I spent hours browsing through the “Games” category of course). Eventually, after yet another reinstall of Windows XP on the family computer, I couldn’t get the USB drivers to work and thus the Internet modem, so I reclaimed the disk space and went to Linux full-time. Linux gaming was not easy back then, but between open source gems like Battle for Wesnoth, console emulators and Wine, I could get by and quickly developed some technical skills.

What prompted you to start contributing to FOSS?

In 2010, I was still using Mandriva Linux but the company behind it was starting to have difficulties which led to debatable business decisions. A major part of the Mandriva community (including former employees who had just been laid off) decided to fork the project into Mageia, a non-profit Linux distribution with a welcoming governance model. I was 18 and joined the Mageia project a few days after the fork announcement, while everything was yet to be built (infrastructure, packages, etc.). I loved the philosophy of the new project and the grassroots approach where all users could get involved, and that there wasn’t a hard separation between the users (“us”) and the developers (“them”). This is still the model that I strive for in all the FOSS projects I invest myself in.

I joined the French translation team. From there I came to join and at times lead the internationalization team, the bug triage team, the quality assurance team, and finally the packagers/developers team. I was a student with a lot of motivation and a good amount of free time, so I wanted to learn new skills and be useful to the project. As a packager, I scoured the Internet for cool FOSS games and game technology to package, and that’s how I stumbled upon Godot shortly after its open sourcing in 2014.

Why should others get involved with FOSS?

For me, FOSS is a necessity. Software is intangible and can be copied infinitely without taking anything away from the original owner. The fake scarcity created by commercial licenses and closed code can be understood from an economical point of view, but if you think about what’s best for the users and humankind as a whole, it’s an aberration. And I strongly believe that the best interest of software users should be the priority of any software developer – it’s a matter of ethics to me. Our world runs on software, all of our appliances embed a ton of software, and it must be of the best quality achievable. Only peer review and pursuing the common interest can ensure this, as well as give good guarantees of security and privacy.

Aside from that, FOSS is often created by communities of users and developers who share a common goal, and they can provide a feeling of belongingness that many of us long for. Being part of a FOSS project, knowing that the application you’re using has been made in part thanks to you, is an amazing feeling. You’re not just using a product, you’re using your product. Fellow contributors are often wonderful people and I’ve made many friends over my past ten years of contributions to FOSS projects.

How should they get started?

Use free software. Make conscious decisions to give the priority to FOSS applications over proprietary ones if you don’t have a very strong reason to use the latter (work necessity, must-have feature, etc.). Install F-droid if you have an Android phone and discover the joy of browsing a library of applications which you can be reasonably confident using without having to think “what’s the catch?”. Teach children using free software – they don’t have years of habits to overcome to switch from a proprietary application to a FOSS alternative.

And when you find a project that you really enjoy, follow its development news, visit its forum or chat platforms, get to know fellow users and some of the contributors. See if there’s anything you’d like to do in this community. Do you enjoy communicating with these people? Is there anything you like doing that might be relevant for this project? Is there anything that you’d like to learn from fellow community members? Many FOSS projects have detailed contributing guidelines, mentoring programs to help new contributors, and a wealth of knowledge that they want to share.

What difficulties and limitations do you see with FOSS?

FOSS has come a long way to impose itself as a best business practice for software development, with most companies now building their products on permissively licensed tech stacks (programming languages, libraries, frameworks, etc.). The growth in popularity of FOSS technologies (often better designed, longer-lived and – for the vast majority – free of charge) is amazing, but highlights a core issue of many FOSS projects: funding and maintainability. With a growing number of users (and contributors) comes an increasing need for actually paying the people who develop and maintain the technology, and this is far from a given today. While using FOSS technology often grants companies huge savings in terms of license fees (for proprietary solutions) or manpower (for in-house solutions), there’s only a very small fraction of those saved costs that end up directed towards funding the free technology that those companies rely on.

Another big issue in my opinion is the severe lack of diversity and representation of minority groups in many FOSS projects. In my experience from the projects I contributed to or attending events like FOSDEM, diversity in FOSS seems worse than in the software industry as a whole (and for Godot, also worse than in the game development industry, which is itself known for its diversity issues). I think it’s a very serious problem as this inevitably leads to biases, and a higher barrier to entry for people coming from minority groups (either due to an unwelcoming attitude towards people from minorities, or simply because such projects are less attractive to potential contributors that could increase diversity within the project). And in a world where your public GitHub profile is taken as a factor for recruitment in tech companies, this is additionally an important socio-economic issue.

How can they be solved?

I don’t have fact-based research to answer that, but my feeling is that the lack of diversity in FOSS (at least non-profit, bazaar-style projects like the ones I contribute to) is partly due to the cost of getting involved in such a project: your free time. Not everyone can afford themselves the luxury of spending several hours a week contributing to software projects, and I think we therefore see an overrepresentation of those people who can actually afford it. The core of my FOSS involvement started when I was a student, attending free university in France, doing fairly well in my studies, being supported financially by my middle-class parents… that afforded me time to contribute, develop technical skills, etc., which led me where I am now. I think that not everyone has it so easy, and if I had had to work side jobs to pay my studies or sustain a family, I would probably have used my reduced free time on less time-demanding hobbies.

So I think a way to alleviate that is to continue the professionalization of FOSS development, allowing more people from all horizons to work on Free Software and be paid for it. Initiatives like Outreachy do a great job by allowing people from minority groups to work on FOSS projects as paid interns, often leading to full-time employment. Many companies develop FOSS projects and have increasingly diverse employees, so little by little I see the situation improve.

And this ties back into my earlier point about the funding and maintainability of those FOSS projects which are not driven by a commercial company, but rely mostly on unpaid contributors. If we can get the bigger companies that rely on these projects to play fair and contribute more funds and developer time in these projects (including developer time from some of their employees from minority groups), my hope is that these projects (Godot included) will do a better job at attracting new contributors from those groups.

Finally, we should make FOSS contribution much more accessible and easy, so that anyone with a spark of interest in community-driven projects can have a role without having to dedicate an inordinate amount of time to it. Finding ways for people to contribute maybe a few hours a month and still feel valued and validated as contributors to a project is in my opinion an important factor to increase diversity in FOSS.

Where do you see difficulties in contributing?

In my experience, the main difficulty to contribute to a project is getting familiar with that particular project’s philosophy, design, and workflow. For example if you want to contribute a feature to Godot, it’s one thing to write some code that works and implements the feature you had in mind, but it’s a different thing to make it in a way that will fit the engine’s design, work well with other components, and be maintainable for years to come by the upstream developers. And while we can have guidelines to help assess this, it takes time to assimilate them and the overall project philosophy to understand how to do things “right”. It can take weeks or months of participating in community channels, following discussions on issues and Pull Requests, to understand how the project (and its core developers) tick. Again, time is a big factor, and not everyone can afford it.

Thankfully, there are other areas where contributions can be easier, and a good way to ease oneself into a specific project’s philosophy. Community support, translation, quality assurance, issue triage, talking about the project to friends, colleagues, fellow students or at events – while they all need some amount of “insider knowledge” too, they are much more accessible and in my experience (both with Mageia and Godot) a good way into the wonderful world of FOSS contribution. Many projects also have mentoring programmes where you can be paired with an existing contributor who can help you understand the workflow of the project, as well as help solve technical hurdles you may face.

What does a perfect day off look like?

A full day hike in a beautiful natural scenery in a valley or near the sea, followed by a chill day with friends or family, cooking and eating some nice dinner, and maybe playing a board game or video game together. Yeah I’m greedy, a perfect day off must be two days for me ;)

Do you want to tell us something else we didn’t ask?

Running out of time and I wrote a ton already, so I guess no :D