The Open Source without GitHub & GitLab

The Open Source without GitHub & GitLab

I'm curious about how Open Source is without GitHub & GitLab, the platform that empowering open source project plus an abstraction of Git workflow. I do learn from one of the oldest open source project (Kernel) and one of modern successful open source project (LibreOffice) and live outside Git(Hub|Lab). Plus, that is not handled by a company™.

Current workflow

Beside open source is about transparency, open source is about collaboration. Writing some guide to start contributing is the fundamental way to start accepting works outside the core team.

The workflow are basically like this:

  1. Pick some Issue
  2. Fork the project
  3. Do some work
  4. Push the changes
  5. Do Pull|Merge Request

After that your changes will be merged to the "origin" branch.

GitHub Pull Request or GitLab Merge Request is their own workflow to make Merge action easier (and in fancy way). git(1) doesn't provide that fancy way, but basically PR/MR was an abstraction of that unfacy way.

Uncover the abstraction

By default, only "privileges user" has Push access to the origin repository. Since Git(Lab|Hub) is a (remote) repository hosting, that's why you can fork existing project (from origin maintainer) to your own, do some changes, and push it to your fork on remote host.

So you need to create Merge/Pull Request then the "privileges user" can merge your changes to the origin. Like this one for example:

Did you see that 4 tabs (Convo, Commits, Checks, and File changed)? That was an abstraction of:

  • git-send-email(1)
  • git-commit(1)
  • git-format-patch(1)

"Checks" was basically only some CI things.

And frequently, the conversation is basically between the maintainer (or code owner) with the "contributor" or in some dedicated mailing list so every member (or everyone?) can see it.

For example, this is how someone give a fix of wrong version in cunit.pc from alpinelinux/aports project.

Conversation is here. And the workflow is basically like this:

$ git add some_file
$ git commit -m "[some prefix]: some changes"
$ git format-patch -1 HEAD
$ # or directly
$ git send-email --to="some@email.address" 'HEAD^'

For example the patch file was like this:

Received: from mx12.valuehost.ru (mx12.valuehost.ru [217.112.42.215])
	by nld3-dev1.alpinelinux.org (Postfix) with ESMTP id 22DE17818ED
	for <alpine-aports@lists.alpinelinux.org>; Fri, 15 Nov 2019 05:16:56 +0000 (UTC)
Received: from mx7.valuehost.ru (unknown [127.0.0.255])
	by mx12.valuehost.ru (Postfix) with ESMTP id 33FDF509EC
	for <alpine-aports@lists.alpinelinux.org>; Fri, 15 Nov 2019 08:16:56 +0300 (MSK)
From: alpine-mips-patches <info@mobile-stream.com>
Date: Fri, 15 Nov 2019 05:01:41 +0000
Subject: [PATCH] main/cunit: fix wrong version in cunit.pc
To: alpine-aports@lists.alpinelinux.org
Message-Id: <20191115051656.33FDF509EC@mx12.valuehost.ru>

---
 main/cunit/APKBUILD | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/main/cunit/APKBUILD b/main/cunit/APKBUILD
index 08b9075a67..c1cb119617 100644
--- a/main/cunit/APKBUILD
+++ b/main/cunit/APKBUILD
@@ -4,7 +4,7 @@ pkgname=cunit
 _pkgname=CUnit
 pkgver=2.1.3
 _pkgver=${pkgver%.*}-${pkgver##*.}
-pkgrel=1
+pkgrel=2
 pkgdesc="Automated testing framework for C"
 url="http://cunit.sourceforge.net/"
 arch="all"
@@ -23,6 +23,7 @@ prepare() {
 	autoheader
 	automake --add-missing --include-deps --copy
 	autoconf
+	sed -i "s/@VERSION@-@RELEASE@/$pkgver/" cunit.pc.in
 }
 
 build() {
-- 
2.24.0

Then the author or the maintainer can do a merge like this:

$ (curl|cat) the_patch_file | git am -3

So your changes/contribution to the project will be merged to the origin repo!

Drawbacks

The "Checks" things, yes that CI. Usually some CI services has a feature to do some integration test to current PR so the maintainer can merge the patch without worry while the CI server mark the patch as pass. Its hard to do this since in this workflow we don't have any PR/MR-related style.

We can solve this by using master-(dev|canary|nightly) branch style, obviously. Like what we did although while using Git(Hub|Lab) service.

I don't know does using this workflow is a step backward, you decide it.

Governance

We need to deal with governance on how we welcome external contributors. Take example Kernel project, only one person who can merge the patch to the mainline kernel repository: Linus Torvalds. Yes, you know him.

For LibreOffice, the governance is general. Your patch will be merged after reviewer & CI accepting your patch. Classic, right?

Want more extreme example? SQLite. SQLite is Open Source but not Open Contribution project. They don't accept any patch especially from unknown person. But they welcome any suggested changes in case you have some patch as a PoC. This is understandable to make (either SQLite or Kernel) pure.

Social Coding

Both GitLab & GitHub was promoting social coding as one of their features. You can find the Stars, Contribution heatmap, and Followers feature there because its designed for the shake of social coding.

Yeah, its great for people to make this-open-source things fun, especially for beginner who just getting started to this world/movement. There are a tradeoff from this Social things–like what you feel on any social media platform–that's why I hate that although I'm not the anti-social ones.

TL;DR

I write this to imagine "Can open source works although there is no Social on it?". LibreOffice, SQLite & Kernel is a succesful Open Source project. And that was a mature, huge, battle-tested, and not just-hype-and-cool project in the industry even until today.

I don't create the next SQLite or the next Kernel, but I choose Open Source as a part of my living and a human being.

Thanks for reading this.