Go is moving to GitHub
groups.google.com
groups.google.com
This is a momentous move for Github, especially with Microsoft moving .NET to Github as well. As someone who loves Github immensely, this makes me happy knowing that my favourite service is going to be around for a very long time.
Kudos to the Github team for well and truly making it as the premier code hosting and collaboration tool for developers and lovers of open source. It only goes up from here.
Dart: https://github.com/dart-lang
And lots of other stuff:
https://github.com/microsoft/ and https://github.com/azure/ to name two.
[1] https://docs.google.com/document/d/1jVFkZTcYbNLaTxXD9OcGfn7v...
Go was on Mercurial before so it was already away from any Google own source control system.
How being on Mercurial implies that it was "away from Google code" ? It is in fact hosted on Google code currently (https://code.google.com/p/go/)
PS: Google code supports: subversion, mercurial and even git (https://code.google.com/p/support/wiki/GettingStarted#Workin...)
Well, I doubt that Google Code engineers or project managers had much, if anything, to do with the decision to move the Go project.
Being cautious is one thing, being a sucker for being too cautious is another.
There are things like obvious conclusions.
Considering open source's history, you'd think its primary management tool would be open source as well. I guess it's GitHub's combination of accessible design + performant version control + lack of ads + reliability that made it the premium source for anything open source.
I'm impressed.
Their website design is beautiful, consistent, making it delightful to use everyday. They fix issues quickly, are reliable, and have top notch customer support. They try to be at the top of their game and offer features to make our work easier (while maintaining simplicity, similar to Go). You can edit posts to fix typos, and GitHub Flavored Markdown is efficient to write. They have the best API and docs I've come across.
It helps that once you're familiar with the workflow, if another project you want to make a contribution to on GitHub, it's super convenient (unlike in the past, think SourceForge and others). Even if you're not, the web flow makes it easy to press edit and go from there.
Github enterprise was a disaster with just a couple hundred users.
Under the load of just a few hundred users it died almost every day. Their support team couldn't figure it out. We had to reboot the servers constantly.
We begged them to add an option to reject force push to master. They refused. We ended up monkey patching their obscured source to add the feature, but it broke on upgrades and was hard to maintain. This is something probably every single customer of theirs wants, and it should take one engineer less than a day to implement.
They only just added side by side diff support. IMHO this is a basic, core feature for any kind of code review workflow. I'm holding my breath for proper syntax highlighting while in diff view.
We've since moved on to Atlassian Stash. While it isn't perfect, it's a dream compared to Github enterprise and a lot less $$$ to boot.
> Still, both lack a lot of basic issue tracker and code
> review features.
* The ability to mark which commits/files have been reviewed and so track progress.
* The ability to distinguish resolved and unresolved issues
* The ability to assign a reviewer based on which code is being altered in the PR.
* Useful handling of history rewriting during review.
I also think that the PR model could be implemented in a way that would make for better collaboration. At the moment, if someone submits a PR that has some issues and you want to help them fix those issues it's a huge pain because the commits typically live in their fork to which others usually don't have push access. It would be a considerable improvement if PR branches were set up in such a way that both the original submitter and the people with commit access to upstream could push to the review branch.
We host all of our private repos with Beanstalk, and use GH for our open source repos.
The fact that every comment on a review turns into a separate email is insanity, and just fills up your inbox with crap (one email for all of one person's comments on a review makes a ton more sense).
I hope they make it better, it definitely seems like a place where some TLC can go a long way.
Of course, maybe I missed the memo.
https://github.com/llvm-mirror/clang
Swift hasn't been included but objective c is there.
Is the golang spec still tightly controlled by 3 wisemen in Google and no feature is allowed to add to the language without all three in total agreement?
BTW, I like 98% of their language decide choices and absolutely LOVE the compilation speed of the program.
You'll never get exceptions in Go. No one who has used go for a significant period of time wants exceptions. Error values are far superior (given the other features of the language, like multiple returns and interfaces for the error types).
You should continue to use Go, I don't think you'll miss exceptions after long. I understand the view, though... first time I saw Go I thought "No exceptions? Pass!". But I got over it, and now I've seen the error of my ways :) There's an amazing freedom that comes with knowing that random functions you call can't exit your function without your control.
If by exception you mean Java's implementation, yes. If by exception you mean not allowing programmers to ignore error values, as most Go programs seems to do at least once, no.
I think most of this could be solved easily by either a compiler option or golint rule flagging any time someone does the classic `res, _ := foo()` punt without checking the value before the end of the block or the next time that variable is assigned to. That'd satisfy the “stop repeating C's mistakes” goal most people have without requiring the other changes which true exceptions would require.
You mean like errcheck? https://github.com/kisielk/errcheck
I'm not sure if it can find spots where people intentionally throw away an error like in
val, _ := foo()
func foo() error { ... }
foo() // errcheck finds this
I've noticed most of the intention error punts in dense code where it looked like someone got tired of repeating checks and only checked the errors which happened while they were working. I'd bet a read-before-overwrite policy on _ would catch mostly infrequent environmental failures (i.e. the kind of stuff which only breaks when you're out of space, file handles, etc.).
Not trying to put you on the spot, just curious.
I think the cognitive load of using git is overrated. Yes, it could probably be simpler. No, you probably can't make simple and intuitive for everyone while retaining all the features.
Given that it's also easy to work with e.g. subversion or mercurial and a git bridge, so you can use the client of your choice with a git server, and yet no one seems to do that is an indication that git is sufficiently simple to use.
Evidence? Using my own anecdotal evidence, I strongly disagree.
I checked volume for GUI-related keywords[1] against CLI-related keywords[2].
The GUI-related keywords get ~34,000 searches per month. The CLI-related keywords get ~4,500. My methodology and data aren't perfect, but it's something at least.
Your premises are:
- People use tools that are sufficiently simple.
- People use git CLI instead of git GUIs.
- Git CLI is sufficiently simple.
I've addressed your second premise above. There isn't (and may never be) good data there, though.
[1] git gui; smartgit; git client; git tower; github gui; git frontend
[2] git command; git "command line"; git cli
So, let me restate my argument (which I suspect you may still disagree with - but hopefully this time you'll disagree with what I actually meant to claim...)
The main complaint that I have heard about git is that its command line is an incoherent inconsistent unusable mess. My opinion is that is true, it perceived to be a much bigger problem than in really is - there are lots of CLI alternatives to working with git, and their use is negligible compared to actual git CLI use. Therefore, I suspect, a perfect git CLI would not have made a big difference in adoption.
The other thing is git is incredibly flexible. Almost no one uses all the options, but much like Microsoft Word, everyone uses a different 20%. And I suspect any system with this level of flexibility is likely to be complex. Which is not to say git is at an optimum; only to say that there's a reason there's not an accepted "perfect" CLI (for git or another VCS) - inherent complexity associated with flexibility.
It even uses different words for the same thing - sometimes remove, sometimes rm sometimes -d.
Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".
The reason people don't use other git frontends is that a vast majority of the help topics already out there only reference git itself. So if you want help for rebase, for example, if you're using some frontend that re-kajiggers the command line, all that help is now useless, or even worse, potentially downright incorrect.
AFAIK those usages are semantically different, and consistently so. For example, git pull actually is "repository ref" rather than "remote ref", and will go over the network to fetch the current status of ref from the given repository.
git merge, on the other hand, is simply "git merge ref"; when ref is of the form remote/branch, it will merge the current local state of remote/branch, which should be the state from the last git fetch. git merge does not access the network.
So: semantic differences, represented via different command line syntaxes. It's actually pretty reasonable, and it's pretty obvious if you've taken half an hour to understand the underlying data model of Git.
> Common actions often require obscure command lines, like "make a new branch" which is git checkout -b instead of just "git branch".
Actually, "git branch" is the command to create a new branch. "git checkout -b" is a shortcut for "create a new branch and move to that branch".
They're very close to the same syntax, and the fact that they're significantly different just shows again that the CLI is a mess. If they're so different, they should have significantly different syntax. "space versus slash" is not significantly different. I'm sure I'm not the first person to create a new branch called "upstream/master" :P
The problem with git branch versus git checkout -b is that 99% of the time, what people want to do is create a branch and switch to it. The "create a branch and don't switch to it" could just be a flag on git branch. It DEFINITELY should not be two completely different commands.
> it's pretty obvious if you've taken half an hour to understand the underlying data model of Git
This is the biggest red flag about git's CLI. I shouldn't need to know the implementation to use the UI.
It seems fairly likely that what is considered a reasonable interface or a bad interface has a high level of subjectivity. Why bother getting bogged down with such debate? If you dislike git, use something else. If git is forced upon you, write some simple wrappers which provide the interface you want for your top few most used operations, or ask for help to do so from the people forcing you to use it.
Or just hang around hacker news and complain without anything changing. It's certainly my favourite method of avoiding work :)
And then creating a branch and switching to it. Is it 'git branch -c foobar' or 'git checkout -c foobar'. Was it -c for create? why not allow it on both? And its so easy to fix these things.
This speaks to a fundamental misunderstanding of the nature of Git. You need to know the model of anything to be able to use it properly- you've mixed up Git's model with its "implementation" (probably because Git's model is so lightweight and exposes a lot of its fundamental workings, [as is right for proper usability][1]). This is like saying you shouldn't have to know what files and folders are to open a document in Word, Yes, you should.
[1]: http://en.wikipedia.org/wiki/Seven_stages_of_action#Usage_as...
Also they got a lot of clients that would have otherwise chosen code.google because Google put up barriers in terms of licences.
It's the same effect.
There are only two things that are going to fix it - either something amazingly better comes along (facebook vs myspace) or the incumbent royally screws up (reddit vs digg).
Facebook, on the other hand, is one of a kind. I absolutely must have an account there if I want to do anything Facebook. And good luck getting your data out or interoperating with other social networks.
The money from private side has allowed them to run excellent public service without ads. And the good public service has certainly fuelled the growth on the private side.
More importantly, though, this is a significant compliment to the Go community, for Go to uproot itself and move to where the majority of its users are.
(Though, a small part of me wants mercurial to live on, but it doesn't seem like that will happen)
GitHub = YouTube
SourceForge -> Friendster
Google Code -> MySpace
GitHub -> Facebook
Google Code doesn't really fill Google's mission, so it's not absurd for them not to bother once someone who's truly focused on the space has created a superior competitor.
Google wanted to create a place open source people actually wanted to be, and had reliable hosting, instead of a place people had to sadly live with that was pretty unreliable (no offense meant to my friends at sourceforge).
Doing so jump started some competition in this space.
While github is slowly becoming a monoculture again, it doesn't appear to slowly be growing crappier or less reliable.
I'm sure in 5-10 years something like Google Code will be necessary again.
(Google code was the first engineering project I worked on at Google, for a few years starting in 2006).
Seriously though, yes, that would be really cool, but probably not something you could directly transform google code into. Google Code is a pretty legacy codebase in a lot of ways. It would likely require making a new platform to do such a thing.
1) Go is moving from Google Code to Github
2) Go is moving from Mercurial to Git
This problem seems to generalize quite a bit. Emphasis on surface-level characteristics rather than core differences seems to be prevalent in comparisons of databases, programming languages, web frameworks, etc. This seems quite bad, but I have no idea how to fix it.
[0] http://mercurial.selenic.com/wiki/RevlogNG
[1] http://ericsink.com/vcbe/html/repository_structure.html
EDIT: another blog explaining revlog format: http://gregoryszorc.com/blog/2014/02/05/the-mercurial-revlog...
The reason that arguments about Git vs Mercurial tend to focus on the interface is because it's the only thing that's really different. You can do all the same thing with both tools.
There are a couple of actual real differences: Mercurial's extension capability. Mercurial's named branch capability.
How important they are is a matter of opinion. I find it interesting that Mercurial was hitorically missing some Git features, but they've all been added as extensions (shipped with the core Mercurial distro generally). That's not really something that's so do-able with Git.
Most people, when interacting with their database, use SQL (or whatever native command language it provides), and don't need to worry about the underpinnings.
Most people, when interacting with their source code repository tool, use the command set provided by the tool and don't worry about the underpinnings.
I've had problems with my databases before that forced me to learn about the horrid can of worms underneath. Until I had these problems, I didn't care because it was entirely irrelevant to the thing I was trying to do.
I've thankfully never had enough of a problem with any of the repo tools I've used (cvs, svn, hg, git) that I needed to go diving into the data structure itself to figure out or fix a problem. I hope I never have to, because that's not the job I'm trying to do.
You shouldn't need to care how the tool works in order to use it, unless using it is your primary job. My primary job is writing code for my application, not writing code for my database or repo tool.
If going distributed, hg provides a much more sane initial set of commands that make more sense to people with experience using anything that isn't git. This matters a lot, because those commands are the only things most users ever really care about.
:)
I use hg for almost all my own software development, and it's a great pleasure. I've also used hg professionally in both development and support modes, and if/when I ever get around to starting my own software business, hg or other "safe by default" system will be enforced with an iron fist. It's quite a lot better than git.
Each time I've worked with Mercurial it's like a giant weight is lifted off of my shoulders. I feel great joy instead of dread each time I have to go look on Stack Overflow for "wait, just what magic flag combination do I need to use to avoid destroying all my work?"
There are some minor nits: occasionally I manually need to forward the "master" tag to the latest revision to push it to git and since git doesn't log file moves you can run into "broken" history for a file, where Mercurial doesn't know a file was moved. But in day-to-day use I don't really have any issues.
If you want to change the title, edit/delete comments, close the PR, assign a person or labels then you'll need the proper permissions.
If you want to make changes to the code you'll need to have push access to the same repo (which is usually the case if you're on the same team because then you don't need to use forks). Otherwise you can always amend the commit(s) before merging them into master.
But on the story this is a great move, Github is much nicer than Google Code and more actively supported. I had not heard of Gerrit before and that was a really pleasant discovery. Now to figure out how to get that setup at the office.
I think the Github style works, assuming you have a sufficiently good CI system that can also receive GitHub web hooks.
After farting with different SCM managers, I strongly believe that having raw ssh against directories is really the best way to deal with source code. (feel free to email me if you want a longer discussion... I'm at a conference and can't reply in detail now.)
I did some CyanogenMod development and I really liked gerrit, albeit its poor performance on Firefox (client side app that had weird JS freezes in fx only..)
I've used five different code review tools, and Github is the worst of the five. I regularly bug them (Github) about this, and they know it. I hear rumors they've been working on it a lot.
Github's review mechanisms barely scratch the surface of what's possible.
1) Google's current internal one
2) Gerrit (open source, to be used by Go)
3) Google's old one (Mondrian)
4) Rietveld (open source, but run for free at codereview.appspot.com)
5) Github
I would totally suspect that Phabricator or Review Board would be well above Github (as are 1-4 in my list), but I don't know where. I have little desire to use or explore new code review systems at this point. Four per day is enough for me at the moment.
- Merging a pull request (almost) always creates a merge commit, polluting the change history. Gerrit will automatically rebase the changes atop the master branch head, leaving a nice linear history.
- Pull requests require the contributor to create a public fork of the repository they're committing to. I can see how this works for some people, but I find it gross for each contributor to the Go project to have their own public fork. What a mess.
- Comments on pull requests are sent as soon as they are created. Gerrit allows you to make many comments on a change, as drafts, and then send them all in one go, sending just a single email. This is much easier to manage for a large project.
- Gerrit has the notion of multiple 'patch sets' for a particular change, and you can see diffs between patch sets, so it's much easier to progressively review large changes.
And there are many other small issues with the GitHub pull request process that make it untenable for the Go project.
You can create Pull Requests within a repository. You don't need to fork the repository if you have push access.
- I've been using the "apply mail" flow to avoid merge commits and to squash commits when appropriate (based on Nathaniel Talbott's post http://blog.spreedly.com/author/ntalbott/#.VGVhz5PF_Zs). It will be nice to have something automatic.
- At least contributors with the commit bit can just create a feature branch and a pull request from there. Some open source projects give out the commit bit almost immediately, but with GitHub there's still that initial fork and pull request to prove oneself.
Interested to see how Gerrit addresses this. GitHub doesn't have any way to disable pull requests. :-(
- I've completely disabled email notifications for this reason. There still can be a huge number of notifications in app or via third-party mobile apps. Rietveld is a lot more sane, I only saw notifications for things I was actively working on.
- I usually end up reviewing just the new commits individually. But that requires figuring out which ones I had already reviewed. Not so bad with only a few branches, but I can see it getting out of hand.
I really hope people from GitHub are reading this thread as they are working to improve their tools. :-)
If not then it just seems like switching to git using the present google code host would suffice from a technical viewpoint.
It seems like it must be possible to hook up a bot to github that watches for pull requests and submits them to gerrit... the Juju team has a bot that does that for our Reviewboard integration. It won't work for more complicated workflows that github doesn't support, like dependent branches or whatever, but it lowers the barrier of entry for initial contributors that just want to submit a simple fix. And the more advanced users can just submit directly to our Reviewboard instance if they want the more advanced features.
Also, the public fork on Github is actually a feature - it means others can easily see what you're working on. You need off-site storage for your personal work anyway, right? You're not going to keep it local on your laptop, so you'll need a branch somewhere regardless.
1 and 3 have their usecases, 3 is esp. useful if the branch contains only 1-2 commits, and 1 is useful if the branch contains > 10. You can add test information into the merge commit.
I hope github will take more gerrit features into their tracker or allow tracker extensions, so that we can live with github alone. gerrit still is a UI and performance nightmare.
For Go, we will require that contributors (everyone working on Go) prepare their commit at head (or at least make the commit able to be automatically rebased). It makes no sense to have a merge commit for every single commit. That would add no extra information and double the size of the commit log.
What's the purpose of keeping a commit history at all? Really, what are your use cases? For me, the history is for looking around and understanding a particular change, or for bisecting to help understand a bug. Both of these use cases are better supported by seeing the tree as it actually was when someone was working on it, than by seeing an artificial, rebased history. What's your use case where the rebased version makes sense?
1) The ability to have multiple reviewers, who can provide both human-readable input ("fix this") and machine-readable input ("Code Review +2"). This becomes powerful when you require a couple things to submit, code review and verification that the change works. A TryBot or something can automatically +1 the Verified bit when the tests pass, and the reviewer can +2 the Code Review bit on the assumption that the code compiles and the tests pass. Requiring both makes review easier and the repository less likely to break. Sounds like extra bureaucracy, but it's actually really wonderful.
2) Pushing the onus of merging and submitting to the author, instead of the reviewer. I can say "looks good, fix the merge conflicts" and be done with the review. With Github, the repository owner has to do the merge (or push back and re-review; I pick doing it myself).
Github's code review tool is really aimed at accepting or rejecting; not improving. At least how I use it, anyway.
then I moved to company that uses github. it's really a big shift. GitHub is not as intuitive and It has a long learning curve. a lot of it was time needed to adjust but I really miss gerrit.
gerrit makes it so clear what commits need reviews. in github it's just a list of pull requests. did I comment already? does this need approval? is this already approved by someone else? who? all of these are difficult to see in github but instantly obvious in gerrit.
then at the code level, gerrit uses my whole browser window so on a 30in I can side by side diff any file. GitHub has a tiny viewport and I'm constantly scrolling. it's not streamlined for reading at all and once 5+ comments are there you can give up on reading the code. gerrit has an upper limit on comments too before the ui overwhelms the code but it's way higher.
I think gerrits tools for viewing more lines are better, although phabricators are good. gerrit gives me a copy and paste link to check out exactly the code I am looking at.
and I really enjoy the patch set system over additional commits. it's a lot clearer in a back and forth setting to see code evolve over time and digging patches without making entirely new commits.
gerrit has built in support for automated and human reviews to leave separate scores. aka, you have to pass the tests and get approval. this doesn't exist in GitHub.
extending gerrit with hooks was crucial to our workflow. luckily github delivers there, but as gerrit is open source you can do more to extend it. especially on the ui side.
I have to admit at first I was blown away how weak github is compared to gerrit. I could not understand why it's so popular. now after about a year on github I get it, I get why it's popular, but is still years behind gerrit.
- GitHub sends each comment individually, encouraging "shotgun commenting" instead of a coherent set on the sender side, and leaving the receiver to deal with dozens of individual emails.
- GitHub attaches line comments to the deltas, which makes the comments disappear if the underlying code changes. This makes it easy to "lose" a comment during a review, and forget to check that something was fixed properly. Even if a comment survives, GitHub doesn't track (non-) resolution in any way, so it's still easy to forget to take care of stuff.
- You can't customize things: can't pick your favorite source code font, the wrapping margin, syntax highlighting colors (as it doesn't have syntax highlighting at all), links that open your editor directly on the correct line, etc.
As it happens, https://reviewable.io fixes all these, and has a much lighter-weight integration with GitHub than Gerrit does, not to mention a much friendlier UI. And yeah, it's my own project so I'm obviously biased, but check it out if you're annoyed with GitHub's code reviews but Gerrit/Phabricator are too heavy for your needs.
Also, everyone who uses github whould really check out *Sourcegraph's code review stuff. They show you really useful things like:
- exactly what definitions were added/removed/changed (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)
- a diff with jump-to-definition links (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)
- a list of people and projects impacted by the change (https://sourcegraph.com/github.com/fsouza/go-dockerclient/.p...)
Totally gets rid of the "understanding the PR diff" problem others mentioned
1. This fits better with the workflows I know and are common for Go programmers. I use Github and Git regularly for a variety of things, and I only ever use Google Code and Mercurial for things dealing with the Go source or tool repositories. Along with the change of the much of the compiler source code from C to Go, this will make it a lot easier to get involved with the core of Go.
2. Simplifies using import paths for Go's tools. There's a bunch of different repositories in Google Code's Go project, and using them is slightly more painful because Go Get then requires mercurial to work. Reducing developer friction is a good thing, especially in odd places such as when a github repository uses a Google code repository and suddenly you need mecurial to import something using git.
I still contribute, but the barrier to entry is higher; people have to hunt the ruby home page to find this information which is not ideal.
Not really. Everyone used Git and Github 5 years ago too. That's why it was so annoying that Go chose to use Google Code for everything, although not surprising considering it's a Google project.
No, they didn't.
Github only started in April of 2008, or 6 years ago. Your implication is that they took over the world in a year. They didn't. I actually have seen the growth graphs of both before, and what you say is not even close to true.
if you want an alternative for Gerrit code review, you can also use http://review.ninja. It's also open source, so you are welcome to contribute.
Cheers, Mitch
- No side-by-side diffs? Didn't see any in screen shots.
- The scopes asked for seem very broad. I may be confused, but it seemed like it was asking for write access to all repositories, public and private. I have access to several private repos (but I don't own them) for which this is unacceptable. If the scope is limited to the ones under github.com/me then it's not as big a deal... In any case, the scary scope list prevented me from experimenting.
- What do you exactly mean by side-by-side diff? Currently you have diff view between the current HEAD of the Pull Request branch by the base commit.
- Yes, that is true. This is a known issue mentioned by others and there is definitely a need to fix that. ReviewNinja comes from the GitHub Enterprise context, where you usually can trust the internal tool offering, that's why we kept it simple with the permissions in the first place.
Thank you for the feedback!
Basically, it let's you look at the old code, or look at the new code, or see how they're different, all at the same time.
Inline diffs (github-style) require you to keep a context as you scan through code, and it makes it harder to keep everything in your head.
Anything pushed to the branch of a pull request is an edit on the pull request. Once something new is pushed on to the pull request, the voting in ReviewNinja needs to be repeated.
Furthermore, Issues linked to a commit will be linked to all new commits by Review.Ninja automatically, as long as the issue isn't solve. You only merge, once all issues are solved / it is save to merge.
Cheers, Mitch
We are very open for cool new ideas, features and also contributions on our GitHub repo: https://github.com/reviewninja/review.ninja
ReviewNinja comes from the GitHub Enterprise context (as we use GitHub Enterprise in our company) and we want to offer an open source code review tool for both GitHub.com and GitHub Enterprise.
Bitbucket is awesome! But I think if we want to support on premise installations with Review.Ninja, BitBucket support would be overkill.
Cheers, Mitch
Have we forgotten about: http://lmgtfy.com/?q=github+misogyny ?
I'm not sure github even experienced a dip in traffic.
There are github alternatives, it took me 30 minutes to remove my github subscription and migrate my repos to bitbucket.
How does using Github even remotely contribute to accepting misogyny in our industry?
Github's handling of the affair is difficult to judge from outside. At least it seems that management's handling of this affair did not increase future misogyny at the company.
Github's corporate culture appears to be very anti-woman. There is plenty of available evidence to this effect. There is very little apparent diversity (of any sort) in their large team. https://github.com/about/team
Using Github contributes to the success of this monoculture and encourages tech leaders to revere and duplicate this model. It makes tech more difficult for people outside of that group - the white, straight, male group. It makes tech culture worse.
If I'm aware that you host on Github, I will make sure to consider what your competitors are doing before I use your service.
Do you think that not using services from companies with a monoculture is the most effective way of furthering the cause? I'm all for more diversity in the technology and startup sector, but I do believe that the cause should, and eventually will, be solved by dialogue and focus on the issue - not by silently boycutting the companies. Or am I missing some part of the picture?
I do believe a capitalist-based ecosystem can only be healthy with an appropriate level of competition and alternatives for consumers. Github's progress in the market is worrying in the sense that it seems to be driving towards a monopoly.
Github can never be everything to everyone - if there is no meaningful competition, it's guaranteed that some people will be excluded.
I'll grant you that they all look the same. Doesn't prove much -- Karl Marx looked a lot like Andrew Carnegie.
* The burden of proof that Github doesn't promote misogyny is on Github.
EDIT: I personally use Github, but I cancelled my account after what happened. For new projects I use bitbucket. I actually feel bad when I'm using Github precisely because to a degree it means I'm promoting misogyny.
http://www.dailymail.co.uk/news/article-2649354/Australian-t...
Does boycotting Github for the rest of time over a scandal achieve anything?
Nonetheless, your post has value in that I'm now thinking about gender equality in technology. Thank you.
Boycotting a business for any reason is VERY effective if it affects their profits enough (aka enough people do it). Whether or not it is the right solution, if enough people boycotted Github publicly for not promoting gender equality enough you better believe they'll change their tune.
The problem is that everyone thinks "enough people won't do it" and it becomes a self-fulfilling prophecy. Please don't spread FUD claiming that boycotts don't work. Boycotts which don't garner enough support don't work.
> Have you assessed Atlassian's culture and concluded its constituents promote gender equality?
There is a lot of evidence that Github promotes gender inequality. There is less evidence that Atlassian supports it. Would you rather give a guy who you saw punch his wife in the face $5 or a guy who was rumoured to beat his wife $5?
> Nonetheless, your post has value in that I'm now thinking about gender equality in technology. Thank you.
Awesome! If everyone would put some thought towards it maybe we could come up with the appropriate solutions.