Defining Open Source
The term "source" refers to "source code." This is the creation of the development team, specifically the developers. It consists of lines that structure software and enable it to function.
The term "open" means "available."
Therefore, an "Open Source" software is one whose source code is available and can be used and modified by anyone, according to rules established by a license that comes with the software.
Why Make Pokémon Studio Open Source?
Goals of Pokémon Studio
To explain this choice, it's interesting to recall the main goals of Pokémon Studio:
- Allow everyone to create their own Pokémon game for free.
- Reduce the number of interfaces or software to use.
- Improve the accessibility of the Pokémon SDK game engine and facilitate its update.
We have had a roadmap since the early days of the product.
Of course, we are open to suggestions. You can contribute to improve the product by sharing your suggestions directly on our Discord, in the studio-suggestions channel.
Opening Studio to Spontaneous Contributions
Establishing a Solid Foundation
After over 2 years of development on the software, we believe that Pokémon Studio is stable and mature enough to open the code and allow more spontaneous contributions.
For this, we needed to establish a solid foundation. Therefore, we chose to distribute Pokémon Studio in a proprietary format initially.
The idea was to take the time to build robust code and a set of coherent and accessible interfaces.
Visual Management as an Organizational Principle
From the beginning of development, we have always chosen to organize ourselves using the principles of visual management.
In simple terms, it's a way to make information concrete, readable, understandable, and memorable for all team members. Everyone has access to the same level of information, and decision-making in the team is facilitated.
In the context of a volunteer project, where each contributor is free to organize themselves, it's an excellent way to facilitate access to information and reduce the number of unnecessary meetings.
Here's a list of elements that help facilitate this visual management:
- A task list called "Backlog" which gathers all the elements useful for software development. Needs, priorities, technical details. The goal is to understand at a glance what needs to be done and why. The "how" depends only on the development team.
- Clear, detailed, and simple processes.
Benefiting from the Experience of More Contributors
We follow a project methodology called "Scrumban," adapted to the project's context. It blends the principles of Scrum and Kanban frameworks:
- Development is paced by periods of one month, called "Sprint" or "Iteration".
- Each iteration is introduced by a sprint goal, to lead the team to fulfill it and focus as best as possible.
- We reduce superfluous work and streamline as much as possible with a number of tasks chosen by each contributor based on their availability.
But this framework can be constraining for some, and we, therefore, limit the possibilities of external contributions.
That's why we think that opening the code will allow more developers to participate, especially on operating systems like Linux and MacOS, which are less represented in the team but often requested by the community.
Building a Resume While Gaining Skills
Pokémon Studio is a significant, ambitious, and motivating project. The skills of each team member have contributed to developing the product you know today, and this is valuable experience on a resume when job hunting.
Some team members have even leveraged this experience to find their current jobs.
Accessing Tools Available to Open Source Communities
We are moving from GitLab to GitHub. This may seem anecdotal, but it's an important change for the team as we move towards more transparency and openness to developers worldwide.
By doing this, Pokémon Studio will benefit from:
- GitHub's continuous integration and deployment tools (CI/CD).
- Simplified version release on the three OS: Windows, Linux, and MacOS.
- All the tools usable for free in the context of Open Source projects. In the short term, we plan to use a translation utility named Weblate, allowing everyone to propose a translation of the software's texts into their own language.
What Changes Concretely?
By opening the code, we affirm our desire to contribute to the Open Source effort. This implies moving from a closed project to a community project that can serve everyone, beyond just creating a fan game.
Of course, people which will use the source code won't be the same than those which will use the software.
Concretely:
- The application's source code is accessible to the entire community.
- The community can contribute to development without necessarily being part of the team and without commitment (see the contributing section, however, to contribute effectively and see how your work can be integrated into the code).
- For users, potentially more frequent updates, bringing more changes and improvements.
- For potential developers, contribution from the project and issues via GitHub.
- The main development team's organization is more visible. We have things to propose, and we'll tell you more soon.
- Users can become Studio testers and enjoy certain features in advance.
How Can I Contribute?
As a Developer
You can:
- Read the README to learn useful information and understand the installation procedure.
- Read the Contributing.md file, which helps to understand how the team organizes itself and how to avoid working twice on the same subject.
- Familiarize yourself with the team's code good practices.
- Provide feedback to continuously improve processes.
As a Tester
You can:
- Read the Contributing.md file, which helps you to better understand how the team organizes and figure out what you can test to help the team progress.
- Familiarize yourself with the team's good practices to know how to communicate effectively about your interventions.
- Provide feedback to continuously improve processes.
Are there constraints?
Certainly, you can't do whatever you want, and there are some rules to follow. The Pokémon Studio usage license file summarizes these usage constraints.
These are non-negotiable conditions:
Attribution - You must give appropriate credit to Pokémon Studio and its development team, provide a link to the license, and indicate if changes were made to Pokémon Studio and what those modifications are. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use.
NonCommercial - You are not permitted to make commercial use of this product, in whole or in part, including any materials comprising it. However, you are allowed to make commercial use of any product resulting from its use. This includes any video game created through the use of Pokémon Studio.
ShareAlike - If you remix, transform, or build upon the material comprising Pokémon Studio, you must distribute the modified product under the same license as the original, meaning with the same license under which Pokémon Studio was distributed.
- No Additional Restrictions - You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
External contributors must familiarize themselves with the development workflow and the team's code good practices. These practices will be reminded during the reviews of your Pull Requests. Integrating them upstream streamlines the integration of your work into the application's code.
External contributors must also be aware of the Roadmap to avoid working on the same subject, especially without coordination with the team. Otherwise, the code might be unusable and would be rejected.