The purpose of the blog is to focus on two open source software packages with different licenses and see how different they are in terms of their approaches to the community organization. The software packages that I choose are paimon.moe and Sigil.
paimon.moe is free, open-source website as Genshin Impact companion. Help people plan what to farm with ascension calculator and database. Also track their progress with todo and wish counter. With MIT License.https://github.com/MadeBaruna/paimon-moe
nuclear is a free music streaming program that pulls content from free sources all over the internet. With AGPL-3.0 License.
https://github.com/nukeop/nuclear
If you know mps-youtube, this is a similar music player but with a GUI. It's also focusing more on audio. Imagine Spotify which you don't have to pay for and with a bigger library.
Here is the documentation they provided on GitHub for choosing license: "You're under no obligation to choose a license. However, without a license, the default copyright laws apply, meaning that you retain all rights to your source code and no one may reproduce, distribute, or create derivative works from your work. If you're creating an open source project, we strongly encourage you to include an open source license. The Open Source Guide provides additional guidance on choosing the correct license for your project."
link to the original document: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository#choosing-the-right-license
MIT license is a short and simple permissive license with conditions only requiring preservation of copyright and license notices. Licensed works, modifications, and larger works may be distributed under different terms and without source code.
paimon.moe takes patches from contributors through the source code management system GitHub.
If a user or contributor encounters a bug or problem with the website they can join their discord for faster response https://discord.gg/tPURAYgHV9.
For problems/issues regarding to one of their feature "To Do List" will be ignored since they announced that it is being rewritten from scratch.
One can also became a contributor to the paimon.moe project by doing the translation of the website, for this they will have to visit their corwdin: https://crowdin.com/project/paimon-moe.
For pull requests, contributor needs to create an Issue first with the purpose of the pull request. After the issue is created, MadeBaruna which is the repository owner will step in and check if they can continue with the request. This is to make sure that it is capable of merging, the repo owner will tell them if it is doable or not at first.
From one of the merged pull request https://github.com/MadeBaruna/paimon-moe/pull/216. I noticed that mainly the repo owner is in charge of accepting the merges of the project and MadeBaruna is relatively fast on merging pull requests that have no conflicts. Usually a day or two the pull request will be merged. Not a lot of people/contributors are involved in the process of reviewing the pull request. And if there is conflict in the pull request it is up to the contributor to resolve it. They normally discuss the problems in the issues/or maybe discord.
I think the advantage to this way of how they manage the community is that people are very likely to became a contributor to the project base on what kind of feature they could come up with, basically the barrier is pretty low, and the disadvantage is that one is on their own making the features complete and compatible to be merge into the project. For me personally, if I wish to become a contributor of this project I need to learn about the language Svelte because the project consist of 46.2% code written in Svelte.
GNU Affero General Public License v3.0
Permissions of this strongest copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license. Copyright and license notices must be preserved. Contributors provide an express grant of patent rights. When a modified version is used to provide a service over a network, the complete source code of the modified version must be made available.
Nuclear has many ways to contribute to the Nuclear project: logging bugs, submitting pull requests, reporting issues, creating suggestions, and many others. It takes patches from contributors through the source code management system GitHub. They also take suggestion votes for new features in https://nuclear.featureupvote.com/.
Issues labeled good first issue are good candidates to pick up if one is contributing for the first time. If one is contributing significant changes, needs to discuss it in the issue first before starting to work on it.
Nuclear is also using Crowdin to manage localization. one can check if their language is supported, track localization progress, and help translate Nuclear there. https://crowdin.com/project/nuclear
Nuclear treat code quality seriously, and while they're open to helping out new contributors, they also need to ensure that the contributions meet their standards.
Couple steps before one commit their code:
Run linter (npm run lint:fix in project root) to format the code and automatically detect coding style issues, some of which can be automatically fixed
Run tests and try to build the project (npm test in project root) to make sure that all tests pass and the project can be built with their changes
If they're fixing a bug, or adding a new functionality, need to create tests covering their changes. Look at the existing tests in each package or ask them(Nuclear) on Github or Discord if they're unsure how to do it. Nuclear have automated test coverage checks for pull requests, and require code coverage to never decrease. It's fine if your pull request fails this check initially, but coverage needs to at least stay the same for the PR to be merged.
If you're adding visual components in the ui package, they need to create snapshot tests for them. Most components there already have snapshot tests, take a look at them to see how they should look. Typically they will want the snapshots to cover all the different states the component can be in, and be filled with some example content.
Add new visual components to Storybook (*.stories.tsx files). It's nice if you can also show them some screenshots in the pull request for reference.
https://github.com/nukeop/nuclear/pull/1148
This is an pull request I observed. It is been flagged as under review by the maintainers. In this pull request there was two maintainers working with the contributor trying to make sure that the pull request is passing the CI tests. There are communications involving technical terms in order to solve the problem, it's not just for this pull request but others as well, the maintainers seems very active on helping the new contributors to solve their problem in the pull request.
If I were trying to be an contributor to this project, I would have to learn the language Typescript since the project consist of 68.7% being typescript and also start with those issues that are labeled as good first issue to begin with according to their suggestion.
Top comments (1)
What a topic! I've approached this from both sides - as a hobbyist developer and in my day job.
In my day job, I often choose F/OSS software because it is the best choice. But, when choosing F/OSS, I am very careful with liceneses, because it changes my approach to using the software. I'll use AGPL 3.0 as an example, since you mention it. AGPL is anathema to commercial software. Anything that touches this viral copyleft license is potentially something the author or any of the public users may demand. Therefore it is important to limit the use of such software to internal users only. If there are no public users, the author has no right to the modifications. So, I treat a license like this as hostile, and get as much out of it as the law will allow.
As a developer, I'm looking to abdicate as much responsibility as possible while still allowing others to do whatever they want with my code. MIT fits the bill just fine.
But these are two extremes. Later versions of GPL probably do what you want if you are creating a project for a community. It keeps you apprised of downstream changes, prevents anyone else from making money off of it, but still makes it usable in a commercial environment provided you respect the authors' rights.
I guess I'll end with the disclaimer that I am not a lawyer, I only know a lawyer. This has been my experience with F/OSS licenses. Each one has it's purpose, and you need to choose carefully based on the rights you want to retain.