Add post: Why I think about closing contributions to imag

1 files changed, 93 insertions, 0 deletions

diff --git a/content/blog/2017-09-15-Why-I-think-about-closing-contributions-to-imag.md b/content/blog/2017-09-15-Why-I-think-about-closing-contributions-to-imag.md
new file mode 100644
index 0000000..de5979f
--- /dev/null
+++ b/content/blog/2017-09-15-Why-I-think-about-closing-contributions-to-imag.md
@@ -0,0 +1,93 @@
+---
+title: "Why I think about closing contributions to imag"
+date: "2017-09-15T21:00:00"
+tags: [ "open-source", "programming", "software", "tools", "git", "github" ]
+---
+
+<small>
+    This post was published on both
+    [my personal website](https://beyermatthias.de)
+    and
+    [imag-pim.org](https://imag-pim.org).
+</small>
+
+I'm thinking of closing contributions to imag since about two months. Here I
+want to explain why I think about this step and why I am tending into the
+direction of a "yes, let's do that".
+
+# github is awesome
+
+First of all: github is awesome. It gives you absolutely great tools to build
+a repository and finally also an open source community around your
+codebase. It works flawlessly, I did never experience any issues with pull
+request tracking, issue tracking, milestone management, merging, external tool
+integration (in my case and in the case of imag only Travis CI) or any other
+tool github offers. It **just works** which is awesome.
+
+But. There's always a but. Github has issues as well. From time to time there
+are outages, I wrote about them before. Yet, I came to the conclusion that
+github does really really well for the time being. So the outages at github
+are not the point why I am thinking of moving imag away from github.
+
+# Current state of imag
+
+It is the state of imag. Don't get me wrong, imag is awesome and gets better
+every day.
+Either way, it is still not in a state where I would use it in production. And
+I'm developing it for almost two years now. That's a really long time frame
+for an open source project that is, in majority, only developed by one person.
+Sure, there are a few hundred commits from other, but right now (the last
+time I checked the numbers) more than 95% of the commits and the code were
+written by me.
+
+Imag really should get into a state where I would use it myself before making
+it accessible (contribution wise) to the public, in my opinion. Developing it
+more "closed" seems like a good idea for me to get it into shape, therefore.
+
+# Closing down
+
+What do I mean by "closing development", though? I do not intend to make imag
+closed source or hiding the code from the public, that's for sure. What I
+mean by closing development is that I would move development off of github and
+do it only on my own site [imag-pim.org](https://imag-pim.org). The code will
+be openly accessible via the cgit web interface, still. Even
+contributions will be possible, via patch mails or, if a contributor wants
+to, via a git repository on the site. Just the entry gets a bit harder,
+which - I like to believe - keeps away casual contributors and only attracts
+long-term contributors.
+
+# The disadvantages
+
+Of course I'm losing the power of the open source community at github. Is this
+a good thing or a bad thing? I honestly don't know. On the one hand it would
+lessen the burden on my shoulders with community management (which is fairly
+not much right now), issue management and pull request management. On the
+other hand I would lose tools like travis-ci and others, which work flawlessly
+and are a real improvement for the development process.
+
+# The conclusion
+
+I don't really have one. If there would be a way to include Travis into a
+self-hosted repository as well as some possibility for issue management
+([git-dit](https://github.com/neithernut/git-dit) isn't ready in this regard,
+yet, because one cannot extract issues from github just yet), I would switch
+immediately. But it isn't. And that's keeping me away from moving off of
+github (vendor lock in at its finest, right?).
+
+I guess I will experiment with a dedicated issue repository with git-dit and
+check how the cgit web interface works with it, and if it seems to be good
+enough I will test how it can be integrated (manually) with emails and a
+mailing list. If things work out smoothly enough, I will go down this road.
+
+What I don't want to do is to integrate the issue repository in the code
+repository. I will have a dedicated repository for issues only, I guess. On
+the other hand, that makes things complicated with pull request handling,
+because one cannot comment on PRs or close issues with PRs. That's really
+unfortunate, IMO. Maybe imag will become the first project which heavily uses
+git-dit. Importing the existing issues from github would be really nice for
+that, indeed. Maybe I'll find a way to script the import functionality. As I
+want a complete move, I do not have to keep the issue tracking mechanisms
+(git-dit and github issues) in sync, so at least I do not have this problem
+(which is a hard one on its own).
+
+