The MoodleNet team use products and services from GitLab Inc. to develop the MoodleNet code base. We were therefore disappointed to learn of a recent decision by GitLab Inc. to change their policies around who they will and will not do business with.
As reported in The Register, GitLab Inc. first updated their policies to declare that they “won’t ban potential customers on “moral/value grounds,” and that employees should not discuss politics at work”. However, after a substantial backlash from current and potential customers, they have modified their position to “get rid of the problematic passages put forth in [the] handbook change”.
The internal policies of other companies might seem irrelevant to the work we are doing at Moodle, but it is important that, as a purpose-driven organisation, we use the influence we have to make our world a better place. Our values include integrity (“we employ the highest ethical standards, demonstrating honesty and fairness in every action that we take”) and openness (“we strive to be open in our goals, our tools, our processes and our results, as much as is practical”).
We believe that in order to live up to our values of integrity and openness, we should make decisions of which our community can be proud. While it would appear that GitLab Inc. have partly reversed their decisions based on the firestorm of criticism they have received, we have nevertheless decided to remove the MoodleNet repositories from gitlab.com and move them to a self-hosted solution. We will provide a further update on this after the Global Moot in Barcelona next month.
Note: the MoodleNet project is set up differently to the Moodle LMS and Workplace projects. Last year, we made the pragmatic decision to use gitlab.com (an instance of the GitLab open source software operated by GitLab, Inc.) to ensure that our project was as open to contributors as possible.
Our intention was always to move the project’s repositories to an even more open and decentralised solution at an appropriate time. Now that time has come, we are evaluating a variety of options, including the ForgeFed project. Although we may decide to mirror our repositories on centralised services such as GitHub, we believe it is important for the canonical location of our code to be under our control.