3 ms·

Kind of telling that of the other comments I see here so far, nobody seems to be addressing what the article is about: because they don't trust github, a for-pr

by jordigh 11y ago

Kind of telling that of the other comments I see here so far, nobody seems to be addressing what the article is about: because they don't trust github, a for-profit company who hides their source code, to not some day pull a Sourceforge. We had this discussion in the GNU project. The basic conclusion I could see was that simply using github as a place to host the repo like Linus does with Linux is not a problem. In typical GNU fashion, the biggest problem people saw was with the non-free javascript that entails from using the github web interface. Some also were concerned with whole SaSS problem with github, were they tie you up with wikis, bug trackers, pull requests and a lot of other things around just git hosting that are difficult to transplant to another service.

aaronbrethorst 11y ago
they tie you up with wikis, bug trackers, pull requests and a lot of other things around just git hosting that are difficult to transplant to another service. Are you saying that some people say GitHub should be avoided for GNU projects because it's too useful?
- worklogin 11y ago
  No, if you read the exact sentence you quoted, it should be avoided because those value-adds are lock-ins that are hard to move to a new service.
  - aaronbrethorst 11y ago
    No one's forcing you to use GitHub's wikis, issue tracking, or pull request facilities. One would only use these features if they were useful. Hence my question.
    - cha0s 11y ago
      Embrace the usefulness! http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
- jordigh 11y ago
  No, but that's a common criticism of the GNU project, that we think anything useful should not be done. The overall issue with SaSS is this. Bit tl;dr, but worth reading it when you have the time: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... In the private discussions I saw, there was some disagreement over whether Github is SaSS or not, but many felt like it was. (Btw, the official stance is that there is one GNU project with many packages, and all of these packages form part of the GNU operating system. So R, GIMP, Gnome, and Octave are GNU packages and part of the GNU project and operating system.)
- bonsai80 11y ago
  "tie you up" might have been better written as "lock you in". Those tools can certainly be made available through other means via free (as in freedom) software. It takes work in doing so and that's what Github is selling - ease and convenience. Github has obviously done a great job of making these tools useful and approachable. The point about having ultimate control over that data though is valid. Github might be able to mitigate some of these concerns with something like Google's "Data Liberation Front", providing a contractual agreement with users to make their data easily exportable if they choose to do so. Of course, even that may not be enough for some projects and for them it's a totally valid option to avoid github (and similar closed SaaS options).
  - sytse 11y ago
    GitLab CEO here, we want to give people options to prevent lock in. GitLab CE already has a one click importer for all your GitHub.com repo's and issues. We're working on automatically importing your pull requests and wiki's too.
    - thedaniel 11y ago
      Do you provide an export function as well, to prevent lock in?
plorkyeran 11y ago
The wiki is trivial to export (it's just https://github.com/gollum/gollum https://github.com/gollum/gollum, and you can clone the git repo with your wiki data directly). Issues and PRs are less trivial, but there's nothing inherently difficult about writing an exporter. The lock-in mostly comes from the ecosystem of third-party tools that's gradually developing which either only support github or work poorly with other hosts.
pbreit 11y ago
"nobody seems to be addressing what the article is about" Possibly because the page is unreachable (for me, at least).
oever 11y ago
For WebODF, we also use GitHub because WebODF is a JavaScript project and there are many JavaScript programmers on GitHub. I'm also a member of the KDE community as is boud with the Krita project. But KDE was traditionally more a C++ community. That is becoming more diverse now. I agree with all the points in the blog, which is why I posted it. But moving WebODF to a separate server would remove a lot of the easy of accepting contributions, so we're not doing that at the moment.

by jordigh 11y ago

aaronbrethorst 11y ago

they tie you up with wikis, bug trackers, pull requests and a lot of other things around just git hosting that are difficult to transplant to another service. Are you saying that some people say GitHub should be avoided for GNU projects because it's too useful?

worklogin 11y ago
No, if you read the exact sentence you quoted, it should be avoided because those value-adds are lock-ins that are hard to move to a new service.
- aaronbrethorst 11y ago
  No one's forcing you to use GitHub's wikis, issue tracking, or pull request facilities. One would only use these features if they were useful. Hence my question.
  - cha0s 11y ago
    Embrace the usefulness! http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish
jordigh 11y ago
No, but that's a common criticism of the GNU project, that we think anything useful should not be done. The overall issue with SaSS is this. Bit tl;dr, but worth reading it when you have the time: https://www.gnu.org/philosophy/who-does-that-server-really-serve.html https://www.gnu.org/philosophy/who-does-that-server-really-s... In the private discussions I saw, there was some disagreement over whether Github is SaSS or not, but many felt like it was. (Btw, the official stance is that there is one GNU project with many packages, and all of these packages form part of the GNU operating system. So R, GIMP, Gnome, and Octave are GNU packages and part of the GNU project and operating system.)
bonsai80 11y ago
"tie you up" might have been better written as "lock you in". Those tools can certainly be made available through other means via free (as in freedom) software. It takes work in doing so and that's what Github is selling - ease and convenience. Github has obviously done a great job of making these tools useful and approachable. The point about having ultimate control over that data though is valid. Github might be able to mitigate some of these concerns with something like Google's "Data Liberation Front", providing a contractual agreement with users to make their data easily exportable if they choose to do so. Of course, even that may not be enough for some projects and for them it's a totally valid option to avoid github (and similar closed SaaS options).
- sytse 11y ago
  GitLab CEO here, we want to give people options to prevent lock in. GitLab CE already has a one click importer for all your GitHub.com repo's and issues. We're working on automatically importing your pull requests and wiki's too.
  - thedaniel 11y ago
    Do you provide an export function as well, to prevent lock in?

plorkyeran 11y ago

The wiki is trivial to export (it's just https://github.com/gollum/gollum https://github.com/gollum/gollum, and you can clone the git repo with your wiki data directly). Issues and PRs are less trivial, but there's nothing inherently difficult about writing an exporter. The lock-in mostly comes from the ecosystem of third-party tools that's gradually developing which either only support github or work poorly with other hosts.

pbreit 11y ago

"nobody seems to be addressing what the article is about" Possibly because the page is unreachable (for me, at least).

oever 11y ago

For WebODF, we also use GitHub because WebODF is a JavaScript project and there are many JavaScript programmers on GitHub. I'm also a member of the KDE community as is boud with the Krita project. But KDE was traditionally more a C++ community. That is becoming more diverse now. I agree with all the points in the blog, which is why I posted it. But moving WebODF to a separate server would remove a lot of the easy of accepting contributions, so we're not doing that at the moment.