GameForce. Part 3, Pros Cons and Pitfalls of an open-source project

As I’ve mentioned in the last article, this is the first time I am going to try to maintain an open-source project (the repository can be found on GitHub by the link). And this brings a set of unique considerations that I would need to take into account. Working on an open-source project is different from working alone or working as part of a team. You can’t know who would want to contribute or what kind of experience they have. But the good news is that a lot of the issues can be alleviated without the need for direct involvement from yourself. It is possible to configure your repository in such a way that it would be easy for contributors to figure out how they can get involved without scaring them off. Here are the things that, in my opinion, are necessary to avoid some of the major pitfalls related to running your open-source project:

Choose your license wisely

Licenses in open-source projects serve as legal agreements that dictate the terms and conditions under which the software or creative work can be used, modified, distributed, and shared. The fundamental idea behind licenses in open-source projects is to provide a framework that encourages the free sharing of knowledge, fosters innovation, and promotes community collaboration. These licenses are called copyleft (contrary to copyright). But the downside of this is that licenses that suit open-source projects usually don’t prohibit commercial use. The good news is that some licenses prohibit third parties from modifying your code unless they are willing to contribute their changes to your repository. Here are some generally used, but different by their nature, licenses, that you might want to consider for your project:

• MIT License: The MIT License is a permissive license that grants users extensive freedom. Basically, you don’t really prohibit anything.
• GPL (GNU General Public License): The GPL is a copyleft license, meaning it aims to ensure that derivative works and modifications of the original software remain open-source and freely available.
• CC-BY-NC (Creative Commons Non-Commercial): CC licenses are considered to be closer to copyright licenses and are usually disregarded by an open-source community (GitHub doesn’t even include CC licenses as an available template). But this is the only way to restrict commercial use of your code. You can find out more about CC licenses and the full text of the license here.

For my project, I’ve selected CC-BY-NC license for now, since I am planning to try to sell it on an AppExchange marketplace. But it doesn’t mean GPL or MIT licenses aren’t practical options. For example, GPL is a great candidate in case you plan to share your code for others to use (like a library or framework) and to get donations from people through Patreon or GitHub donations.

Define contribution rules

It is not easy to convince people to take part in your project. And it is twice as hard to do when it is not obvious how and where to start. Well-defined contribution rules can relieve this uncertainty from your contributors. And vice versa — bad contribution rules can dissuade people from even trying to help. Sure, you should define your contribution rules how you do see fit, but I would say any set of contribution rules should at least answer these set of questions:

1. How can people suggest new features or report bugs? Should they use GitHub issues, or do you plan to maintain a different issue tracker? How do they categorize the issue, or will you do that for them once reviewed?
2. How can developers participate? Who will review the code and what are the best practices? How to configure a development environment for testing?
3. What are the rules when it comes to publicly discussing features and issues?

Remember that once your project starts changing and growing, you’ll probably need to review your contribution rules. You can check the contribution rules for my repository under the link: GameForce Contribution Guidelines

Dedicate time to formalize issues

Remember — you are sharing your code with the entire world. You can’t expect anyone to just look into your code and figure out what needs to be done next. That is where GitHub issues come in handy. You should treat issues only as a feedback tool to get bug reports or suggestions. Instead, you should be using them to track your progress and define the roadmap for your project. There are a couple of rules that I am trying to stick to when I am creating new issues:

1. Issue description should be well-defined and fully describe the scope of the work that needs to be done
2. Use milestones to set the timeframe for the issues and also to prioritize them, so that it is obvious to contributors what to focus on first
3. Use labels so that contributors can easily find the issues that match their skillset

One more thing to mention is that I am not a huge fan of the standard labels provided by GitHub. My personal approach is to have labels that define the “Type” of the issue (Feature, Enhancement, Bugs, Maintenance) and “Category” (you can think of it as a skillset needed). Sometimes I also use “Priority” (Low, Medium, High) to have more granular control inside of the scope of a single Milestone, but this only makes sense once you have a substantial number of issues or a lot of regular contributors.

To sum it all up — maintaining an open-source project feels more like maintaining an online community. And as with any community, with time it evolves, and new issues and problems arise. I don’t expect that my current set of guidelines will cover all the issues that will arise in the future, but they can serve as a baseline for future improvements. And also, they can be a quick-start guide for you and your open-source projects.

Part 4. Backend

Part 2. Gaming achievements in CRM

GameForce GitHub