4 ms·

> This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’

by gkya 8y ago

> This is a beautifully detailed but self-refuting argument. The self-refutation comes midway through, when the author admits: "To be honest I can’t say that I’ve contributed to non-Github projects either." So because I'm not homosexual and not a female, I cannot support gender equality or denounce homophobia? The school of thought that new replaces old no exceptions is boringly wrong. Github flow has its advantages. I as a solo amateur hacker cannot devote the time to maintain my mailing-list+bug-tracker or my gitlab instance, thus putting things on the platform with a wide userbase is a better option. For my private stuff I keep them offline anyways. But I've sent patches both to Emacs via the mailing list and to various OSS projects on github, and the latter was more confusing to me. Still, they were equally useful in that I could get the task done multiple times using them. Just like pen&paper vs. digital. I'm deep into Org mode, notes agenda ox-latex and everything, but many things are just better with pen&paper, and the digital equivalents won't catch up soon (no energy needed, typing on touchscreens suck, touchscreens suck in general, especially when you need to do things quickly, pen and paper are cheap and widely available). Or just like microwave did not kill the traditional oven or replace the stove.

decasia 8y ago
On your substantive point, I have no quarrel whatsoever with mixing old and new tech. I think we all do that, in practice. But what we're talking about is not just whether we mix old and new tech but where we go from here given that GitHub-based development has its problems. If there are good examples of new OSS projects that use mailing list based workflows, I'd love to hear them. The usual examples (see elsewhere in this thread) are, like Linux, usually pretty dated. My view is that the mailing list-based workflow seems to have some real problems and just advocating a return to it is... probably a bit short-sighted. As far as your comments about what makes an argument self-refuting, my point is that it is potentially contradictory to say that X is considerably better than Y even while you can't actually be bothered to do X. If X is "gender equality" then the analogy would be "We should all practice gender equality but as a man I personally want my wife to stay home and keep house." That's self-contradictory in a specific way that "I'm a man and I advocate gender equality" just isn't.
- gkya 8y ago
  On both points, every problem has its own set of best solutions. If your problem is running a big community around a big project where running listserv+debbugs (or the like) is just minutiae, that's the best way to go. If you're medium-to-big, there are umbrella projects that can adopt your project and supply you these tool (e.g. GNU and Apache do this), but your project would need to be useful to some bigger audience and comply with the umbrella project. Otherwise you can just put a the source code up your server as tarballs or VCS repos maybe using one of the readymade web interfaces (viewvc, cgit, gitweb, hgweb, etc.) and hosting your discussions on sth. like librelist.com or google groups; or just use sth. like GitHub or Gitlab without much worry. Principles are best when they are abstract and a few. Then we apply them to concrete situations. If that makes the best answer to perpetually be "it depends", be it so, for its better than cargo cult answers. Also, the discussion does not seem to be around Github alternatives, as the arguments against it in the article could equally be made against Gitlab (a private instance or the public one), Bitbucket or similar. The article is comparing two models, and is not about a post-Github world.

by gkya 8y ago

decasia 8y ago

On your substantive point, I have no quarrel whatsoever with mixing old and new tech. I think we all do that, in practice. But what we're talking about is not just whether we mix old and new tech but where we go from here given that GitHub-based development has its problems. If there are good examples of new OSS projects that use mailing list based workflows, I'd love to hear them. The usual examples (see elsewhere in this thread) are, like Linux, usually pretty dated. My view is that the mailing list-based workflow seems to have some real problems and just advocating a return to it is... probably a bit short-sighted. As far as your comments about what makes an argument self-refuting, my point is that it is potentially contradictory to say that X is considerably better than Y even while you can't actually be bothered to do X. If X is "gender equality" then the analogy would be "We should all practice gender equality but as a man I personally want my wife to stay home and keep house." That's self-contradictory in a specific way that "I'm a man and I advocate gender equality" just isn't.

gkya 8y ago
On both points, every problem has its own set of best solutions. If your problem is running a big community around a big project where running listserv+debbugs (or the like) is just minutiae, that's the best way to go. If you're medium-to-big, there are umbrella projects that can adopt your project and supply you these tool (e.g. GNU and Apache do this), but your project would need to be useful to some bigger audience and comply with the umbrella project. Otherwise you can just put a the source code up your server as tarballs or VCS repos maybe using one of the readymade web interfaces (viewvc, cgit, gitweb, hgweb, etc.) and hosting your discussions on sth. like librelist.com or google groups; or just use sth. like GitHub or Gitlab without much worry. Principles are best when they are abstract and a few. Then we apply them to concrete situations. If that makes the best answer to perpetually be "it depends", be it so, for its better than cargo cult answers. Also, the discussion does not seem to be around Github alternatives, as the arguments against it in the article could equally be made against Gitlab (a private instance or the public one), Bitbucket or similar. The article is comparing two models, and is not about a post-Github world.