Eric Wong on why Unicorn will not be hosted on GitHub(bogomips.org)
bogomips.org
Eric Wong on why Unicorn will not be hosted on GitHub
http://bogomips.org/unicorn-public/m/20140801213202.GA2729%40dcvr.yhbt.net.html
12 comments
The rant is further upheld by his username: 80x24.
Yes, the command line has its place.
Yes, some of us like GUIs even though we can do CLIs.
And using a tool that simplifies some of the trickiness of software development (filing issues, code reviews, etc) is a pretty welcome tool in my bag of tricks. An open source issue tracker is fine, but with his negative attitude towards web browsers, I assume any web-based tool that attempts to get in his software development process would be met with some level of disdain.
Yes, the command line has its place.
Yes, some of us like GUIs even though we can do CLIs.
And using a tool that simplifies some of the trickiness of software development (filing issues, code reviews, etc) is a pretty welcome tool in my bag of tricks. An open source issue tracker is fine, but with his negative attitude towards web browsers, I assume any web-based tool that attempts to get in his software development process would be met with some level of disdain.
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.
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.
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.)
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.)
> 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:
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
How are you gathering up comments and making sure that all issues are addressed, etc.?
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.
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).
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).
Recording of comments is pretty pointless. The code is what matters and that is safely in git. Anything really important should go in the commit message, where it belongs.
If the comments are that important to you then you are foolish to use Github's interface because that means that you can only ever use Github to look at the patch and see the comments. And there's never an indication that the patch even has any comments on it in the git repo itself (rendering git log useless).
It would be much better to use Bugzilla (or something similar) the way Mozilla does, with bug numbers referenced in the commits and commits referenced in the bugs.
There's also "git notes" but it has some funky corner cases IIRC.
I also am not understanding what Github's clunky commit viewer has to do with "pre-merge integration automated testing". That sounds like CI territory.
If the comments are that important to you then you are foolish to use Github's interface because that means that you can only ever use Github to look at the patch and see the comments. And there's never an indication that the patch even has any comments on it in the git repo itself (rendering git log useless).
It would be much better to use Bugzilla (or something similar) the way Mozilla does, with bug numbers referenced in the commits and commits referenced in the bugs.
There's also "git notes" but it has some funky corner cases IIRC.
I also am not understanding what Github's clunky commit viewer has to do with "pre-merge integration automated testing". That sounds like CI territory.
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.
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.)
[deleted]
I wish Gitlab† had a way to do cross-instance merge requests (or more precisely real pull requests) for a completely decentralised experience.
† actually I wish Gitlab, Bitbucket and Github would support that, in an interoperable way.
† actually I wish Gitlab, Bitbucket and Github would support that, in an interoperable way.
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.
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.
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.
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.
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.
I'm a Github user because of the convenience it affords, and I appreciate that. But if I had a mature open source project that wasn't trying to 'grow' as fast as possible, I'd move it off the service.
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.
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.
> 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".
This is true for most people on Github, unfortunately. There's even an oft-repeated name for this phenomenon: "github monoculture".
[deleted]
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.
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.
Agreed. He didn't list one practical reason for his decision. Then again, it's his project, so he doesn't really need to.
"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?
Is that not a practical reason? Why should OSS be behind a ToS?
I think he specifically stressed he's a Free Software advocate. I think the distinction is important.
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.
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....
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....
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.
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.
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.
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.
> 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.
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.
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.
I'm not against github (in fact i like it very much) but issues does seem to impose a little lockin.
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.
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.
As someone else already mentioned, this is not entirely false. You will lose your issues which is a huge reason why big projects don't move to Github. You lose your wikis. You don't run backup of your issues every day, do you? In fact, how many of you do that?
I bet the number is almost zero. Source code is one thing, but the history of discussion? That worth something.
Also, sometimes some repos just don't exist on your computer anymore or out of sync because you done work on multiple computers. Or if your computer is stolen.
I bet the number is almost zero. Source code is one thing, but the history of discussion? That worth something.
Also, sometimes some repos just don't exist on your computer anymore or out of sync because you done work on multiple computers. Or if your computer is stolen.
I don't care about issues or wikis. I don't use either feature in the projects that originate from me (people send me issues but I don't use them to organize development). The code is the important part. Any discussion is already backed up in my email. And even if I did care about issues I could download them through the api, as was pointed out elsewhere.
I don't think this is HN-worthy. Seems like this submission is just trying to stir the pot.
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.).
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.).
Absolutely. And it says a lot about those responding to the post.
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?
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?
>>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?
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?
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.
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.
fossil does this already:
http://fossil-scm.org/index.html/doc/tip/www/index.wiki
It's likely not the only one out there though.
It's likely not the only one out there though.
He's referring to using Github as the communication platform /medium between developers, contributors and users.
I'm surprised gitorious has not been mentioned.
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/
"bogomips"
Cheers that's helpful.
http://bogomips.org/
"bogomips"
Cheers that's helpful.
[deleted]
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.