
Eric Wong on why Unicorn will not be hosted on GitHub - stevengg
http://bogomips.org/unicorn-public/m/20140801213202.GA2729%40dcvr.yhbt.net.html
======
zyxley
So... what about using Gitlab ([https://about.gitlab.com/gitlab-
ce/](https://about.gitlab.com/gitlab-ce/))? It's open source (MIT license),
it's a (very polished) clone of Github's functionality and workflow, and it
can be self-hosted.

Someone saying "please use Github" doesn't (usually) mean they only want,
specifically, Github. It means they want a tool with visual forking and merge
trees, a code browser that can easily reference different branches and tags,
basic issue tracking in a way that can be linked to specific commits and
merges, and so on.

Honestly, at the point that Mr. Wong mentioned "no need to ever touch a
bloated web browser" it felt more like ranting against ~these goddamn stupid
casuals who can't even bother to use the command line!!~, not about actually
bothering to even try and understand what the person was requesting.

~~~
erikb
Git is one of these tools you don't use right if you don't use it in the
shell. Otherwise it's like trying to fly a submarine. You might make it work
if you attach enough stuff, but still it's better to use it under water or to
use a real aircraft. And seriously, if you use it in the shell there is not
the slightest need for Github. I love Github, but there is no additional
information you gain from using it. It's just pretty.

edit: You will probably argue why you want to use git but don't want to use a
shell. Please don't. If you really want to learn something, try git in a shell
for a year (consistently learning, not just getting stuff done with minimal
effort). If you start to use `git log` more often than any gui tool, if you
merge, fork, and `rebase -i` without thinking about it, then make a decision.
And if you reached that point and still think git can live without a shell,
please (seriously) come back here and tell us about it.

~~~
lomnakkus
False dichotomy. It's quite possible to use both.

One thing that git stinks at is line-by-line code review, for example. While I
don't necessarily think GitHub is especially good for that, it does do the job
in a much simpler way. (Yes, I'm aware of the practice of mailing patches for
review, but you're not going to convince very many people that it's better
than a GUI-type thing. It also doesn't address stuff like automated pre-review
and pre-merge integration test runs, etc.)

~~~
__david__
> One thing that git stinks at is line-by-line code review, for example.

Really? That's one thing I haven't ever seen anyone do better than plain old
'git log -p'. I use this alias:

    
    
      [alias]
          review = log -p --reverse
    

After `git fetch`-ing I copy the hash range that I fetched and paste it after
`git review`. Then in Less I can type "/^diff" to use n and p to skip back and
forth between commits. I find this is _much_ easier to read than Github's html
diff views and _infinitely_ more efficient than the millions of clicks I need
in web browser to do anything (plus there's absolutely no lag, unlike the
browser).

~~~
lomnakkus
How are you gathering up comments and making sure that all issues are
addressed, etc.?

~~~
__david__
By talking to the person, in person or on the phone or IM or email, depending
on the priority of the question/issue. If something needs to be addressed then
it goes into the bug tracker (whatever that might be). For egregious things,
we might even `git revert` the patch and let the person rethink/rework it.

~~~
lomnakkus
That doesn't address the actual _recording_ of the comments such that they can
easily see the context of your comments. It also doesn't adress pre-merge
review and pre-merge integration automated testing.

In short: No. Although I'm happy that your process works for you it doesn't
(and won't) work for a lot of other situations (including mine at my current
place of work nor my previous one).

~~~
erikb
I don't get your problem with automated testing. In my eyes this is the one
feature that the shell has, but Github doesn't. That's why I'm quite confused.
You can addd git hooks to automate it, or simply call the corresponding
command while you are in the shell already. But GitHub neither builds nor
tests your code, it simply shows you the git log, git diff, etc. as HTML.

~~~
lomnakkus
Oh, sorry, I guess I wasn't very clear. I was talking about automated
_integration_ testing, i.e. testing on a wholly different system than the
developer's machine. (This is to eliminate the "well, it works for me!"
problem.)

------
mbleigh
The danger of a proprietary centralized service is directly proportional to
how irreplaceable it is and how difficult it is to get relevant data back out.
By this measure, GitHub poses very little threat.

Because it's DVCS, the code already exists on the author (and likely dozens of
other users') machines. With the change of a remote GitHub as a source host
can be effectively replaced.

When it comes to the non-source-hosting capabilities of GitHub, sure they're
proprietary but they too can be replaced. GitHub has gained dominance in the
open source community because it's very good at what it does. If it ceases to
be the best place to host open source projects, people will stop hosting open
source projects there.

That being said, the authors of awesome open source projects have zero
obligation to put their stuff on GitHub if they don't like it. They just might
miss out on contributions of members of the community who don't want to jump
through extra hoops.

------
Zikes
It's fine if he doesn't like Github, but the condescending attitude towards
people that don't mind leaving the terminal isn't doing him any favors.

~~~
adityab
Strawman.

The alternative to using the CLI is not Github. He dislikes the fact that a
large % of new users of git are wholly dependent on a _proprietary_ service.

This is a very understandable attitude if you are involved in the 'older' open
source communities, where people still care about _free software_ in the
freedom sense, and do not simply treat open sourcing as a PR advantage.

Understand this: If you require contributors to your project to use
Github/similar services, these users are filtered by those who are willing to
accept an unreasonably coercive ToS - and yes, most ToSes of American cloud
companies are coercive.

It is not a condescending attitude towards people. It is a deep caring for the
principles of software freedom - freedom for both users and the people who
make the software.

~~~
Zikes
It's not a strawman, the statement at the end of his email strongly implies
that he considers people using Github to be incapable of using git without it.

Besides that, nobody would be required to create an account on Github to
contribute. The primary repository could be hosted right where it is, with
Github available as another avenue of contribution and communication.

~~~
adityab
> strongly implies that he considers people using Github to be incapable of
> using git without it.

This is true for most people on Github, unfortunately. There's even an oft-
repeated name for this phenomenon: "github monoculture".

------
heygrady
Seems like a logical extreme. Github is largely compatible with normal git.
For instance, I've use other git services, like Bit Bucket, and not noticed
much of a difference. While it is certainly for profit, it also offers some
really useful tools that make hosting open source software and communicating
with developers really easy. Github is useful for web developers in particular
(I'm one) but I imagine other developer communities would benefit.

It seems like a hollow argument to malign Github just because it wrapped
something useful in its own right (Git) with a set of tools that raise its
usefulness enormously (Github). And if you end up having an issue with Git, if
you've got a local checkout it's 100% Git compatible and you can migrate it
anywhere you'd like.

~~~
tdsamardzhiev
Agreed. He didn't list one practical reason for his decision. Then again, it's
his project, so he doesn't really need to.

~~~
mkal_tsr
"Github is proprietary communications tool which requires users to accept a
terms of service and login."

Is that not a practical reason? Why should OSS be behind a ToS?

~~~
yeukhon
I think he specifically stressed he's a Free Software advocate. I think the
distinction is important.

~~~
mkal_tsr
Well, for me at least, his advocacy for Free Software is irrelevant to his
assertion that his open source project should not require a ToS and login to
contribute to. It might explain his motivations, but it doesn't invalidate his
position, imo. Others may agree or disagree with him (or I) on these things.

~~~
yeukhon
I am not sure. This is a somewhat difficult to argue but if he called himself
a free software supporter, I think he's more than just an open source
advocate. He's a free software advocate so he rejects any proprietary software
right away.

Popular OSS such as Firefox and Python still require you to register on their
own system before you can submit a bug report. Is that behind a ToS? Yes.
Thus, ToS or not is not the issue here. His entire point is his rejection of
using any proprietary, for-profit service to run and manage his project --
because he's a FS advocate.

I am not from the Free Software camp, but in the old days, when sourceforge
was still popular, I believe any free software hosted on sourceforge would be
considered a violation of Free Software.

[1]: [https://www.gnu.org/philosophy/open-source-misses-the-
point....](https://www.gnu.org/philosophy/open-source-misses-the-point.html)

------
cheald
The message here seems to be "No tooling is better than proprietary tooling".

Hosting on Github wouldn't diminish the ability for people to contribute to
Unicorn via the same channels they do now. It would just make it more
convenient for the many people who already use it.

------
yeukhon
For big projects like Linux or Python, they don't move to Github because they
have their own system running for years. They just don't see the benefit and
they find their existing mechanism effective. Many projects today still run on
Bugzilla, mailing list and IRC.

For smaller projects the cost to migrate from older services like Google Code
or even from Bitbucket to Github (or sometimes from Google Code to Bitbucket)
is not trivia. I think one reason why Django still use its own system (Trac)
rather than going for full Github is the difficulty to migrate old issues
over.

So if the reason is "because we have a solid process in place" it is
understandable. But actually, running your own system is also a lock-in but
you just happen have full control of the system. You are lock in because you
are still using that one software which may or may not continue to exist in a
few years. If next decade you decided you don't want mailman to run your
mailing list, instead you want to use MailFooBar, you will need to prepare
migration. The only advantage is you control your stack, your data. Github can
shut down next year all the sudden and you can lose everything (this is
particularly true and dangerous for people whose software development cycle
depends on small start-up services out there).

I think the attitude is a bit strong to potential contributors, even though I
can see the reason why it's bad for an established project to consider any
migration. It's a personal preference. If you are the main author and you
don't want to move, you don't have to move. I don't have time to manage a full
system. Heck, I don't have any open source code that is popular enough warrant
me to think about running a mailing list or a buildbot farm. Github is perfect
for me for just tracking and sharing code with the world.

~~~
__david__
> Github can shut down next year all the sudden and you can lose everything…

This is entirely false, if github shuts down tomorrow you don't lose
everything. In fact, most likely you don't lose _anything_ , since the git
repo on your computer has everything. This is the only reason I use Github,
myself. It's not like the old days of Sourceforge hosted CVS servers where you
didn't actually have access to your data.

~~~
anko
How about github issues? Is there a way to export that info?

I'm not against github (in fact i like it very much) but issues does seem to
impose a little lockin.

~~~
mbleigh
The GitHub API is extremely robust. You can export issues, including comments
etc. to JSON with a script that will take you maybe 10 minutes to write, max.

~~~
sharyanto
There should be (or is there already?) a script that automatically downloads
an issue and its conversation in text or JSON format and commits it so the
data/archive is in the git repo.

------
xnxn
I don't think this is HN-worthy. Seems like this submission is just trying to
stir the pot.

~~~
PeterWhittaker
I understand your thinking - but I do believe that discussion of the ethics
surrounding technology have a place on HN.

Not to mention that this question leads directly to the "how to build a
successful business on OSS" question, which is itself of direct interest to
many here - and that question is itself entwined with questions of ethics and
law (copyright and trademark law, contract and employment law, ethical
questions of balancing proprietary and community code and access, etc.).

------
MetaCosm
Couldn't anyone choose to create a mirror on Github and do the busy work of
shuttling patches back and forth? If the accessibility is important to them,
can't they independently solve this issue?

Furthermore, if this is as important as implied, wouldn't that Github repo
become an important source of progress for the project, without infringing in
any way on Eric's desire to NOT use (or depend on) Github?

------
th3iedkid
>>It absolutely sickens me to encounter users who seem to be incapable of
using git without a proprietary communications tool.

What is the proprietary communication tool which seems a must for git to
work?Are they referring to SSH?or Something else am not aware?

~~~
warbiscuit
I think he meant github, and the various features it offers, such as issues,
pull requests, and threaded discussions thereof.

I'm also not a fan of github's monoculture (or for that matter, of git's -- i
rather like mercurial). I've only got one or two open-source projects out
there, but I've encountered the "you are aware of github, right? why are you
using <insert anything else>" mindset before.

Ideally, git or mercurial or some dvcs gains the ability to track messages and
issue tracking within the repository allowing multiple frontends (such as
github) to make use of a common backend model. But until then, while github is
nice, I think it shouldn't be a necessary requirement for running a project,
merely a sufficient one. Homogeny breeds fragility, and all.

~~~
johnny22
fossil does this already: [http://fossil-
scm.org/index.html/doc/tip/www/index.wiki](http://fossil-
scm.org/index.html/doc/tip/www/index.wiki)

It's likely not the only one out there though.

------
sefjklsffsdfjkl
I'm surprised gitorious has not been mentioned.

------
corobo
On the other hand if it was on Github at least know how I could find more
information about what it is.

[http://bogomips.org/](http://bogomips.org/)

"bogomips"

Cheers that's helpful.

