That would require these various teams at Microsoft to act as if they were a single organization. This has historically been difficult for teams at Microsoft.
This Github account is definitely run by Googlers (Will Norris and Ilya Grigorik). It was announced on one of the internal mailing lists a few days ago as a companion to code.google.com for things like rubygems, not as a replacement of any kind.
any chance they (or github, or someone else) will enable bidirectional syncing of changes? It'd be nice to see 2 or 3 of the ones out there support not just importing, but also methods for automating the syncing of changes, especially if that means that I can do a github pull request and it automagically becomes a branch or patch file sent to an svn-hosted project.
And if they did acquire GitHub, then I'm sure they'd make all private repos free and create even more of an incentive to use the service. And perhaps the GitHub FE would simply then come bundled with a Google Search Appliance?
I know! It would be horrible to have the service be free, and integrated with Google's other search and social features and therefore more visible to the world!
Yeah and if they buy github maybe they can integrate social coding features using Google Plus and force hackers to code using their real names. The horror...
In all seriousness, I’m happy for them to index my public repositories, but no, I don’t want my email program to show me “relevant” ads based on my private repositories or integrate the contents of my private repositories into their profile of mine.
How would one advertise based on the contents of a repository anyways? Searching for a lot of swearing in the commit messages and recommending anger management?
On a serious note, I would guess that having your commit history and cross referencing it with the issues db (seeing things you closed or breaks caused by your code) might be quite interesting to a recruiter and a source of some pretty targeted (read: expensive) advertising.
[edit: not to mention company lawyers looking to sue some NDA violating employees]
Perhaps you could grep for common libraries like "ffmpeg" and make a guess as to what sort of software it is. Maybe a video editor/player in the case of ffmpeg. Once you figure that out, you could show advertisements for the same sort of software.
site:github.com <terms> is all the integration that I need.
So it's already free, it's already integrated into Google's search, if I want to be social about what I'm coding I can easily share it on G+...
What problems would be solved by doing anything differently?
If Google bought it and nothing changed I'd be happy!!! However, I don't think that'd be the case. Things would change and I suspect for the worse, since it's not a big cash cow like search is.
I think most of githubs innovations could likely be added to google code without acquiring github. The technology isn't really what makes github special.
That's utterly chilling. They'd definitely do another snuff job and then put out a cutesy video about how they're making all this mean old complex stuff quirky and easy and fun.
My favorite response was on Quora where someone asked a similar question and mentioned that "Most GitHubbers wouldn't even pass a Google interview". I certainly wouldn't. And would promptly get myself fired within the week.
Only if you swear at all the interviewers Holman. (jokes :D)
The biggest problem with google acquiring github is that github would be expected to integrate with google's infrastructure; which would be a monumental engineering task. I can't see that happening in any way that wouldn't hurt github somehow. The best case would be that months of github's engineering time is taken away from new features. The worst case is that github is integrated with google code somehow; which would probably result in a revolt by github's users.
I think an acquisition by google would only hurt the open source community. Google likes us too much to risk that.
How much cash does Github have to keep the last 50 or the next 150 feeling special? This is where managing the business starts to get really hard.
I'd assume that the GH founders and first tier employees have probably each banked about $1M so far. A Google acquisition valued at $30-50M would set all of them up nicely and let them move on to other endeavors.
In my opinion, only a very generous profit sharing program or a planned acquisition strategy explains the complete lack of rogue employees blogging their gripes. Keep in mind all the drama at Twitter when it was small.
I don't disagree with that at all, but the cynic in me feels like even with such an amazing team the org stuff gets harder (cash aside) as the company grows.
However, GH has always exceeded all of my expectations in every possible way, so good luck to you guys whatever path you choose.
I wouldn't say either of these statements are true. This is a DVCS doing what it should do: the source is easily distributed across multiple platforms. That's not a white flag, that's just embracing the technology. Remember that Google is supposed to want what is best for the web, it builds products to support that goal, but that philosophy doesn't preclude using other products (for example, Google is on Twitter).
Google Code is not going away, certainly. And I don't think Google has any real interest in GitHub: it's a product that would require such a large amount of retooling to work on Google's architecture that it would be cheaper to clone missing features into Google Code.
One notable difference is that you cannot give Google money in order to get private repositories.
For private work I've been doing Google Code by far best matches our needs. (Your needs will be different.) One place we use Github and the other is Bitbucket. I really wish Google would take our money.
One startup we are paying and one we aren't. Paying does give you a phone number to call. However it doesn't give you anyone useful that answers the call.
I can't seem to follow them, and I do hope Google starts using Github instead of Google Code. Github is by far the best website for open source projects.
It's all mainly due to using git and its interface. Github has a great website design.
as best I can tell, that appears to be a limitation of organizations on GitHub. For example, it doesn't look like you can follow github.com/facebook or github.com/yahoo either.
The thing I like the most about GitHub is that it puts the code first. You go to a web site, and you see these things, in roughly this order:
1. The code.
2. A descriptive readme, which GitHub has successfully trained people how to write.
3. Some miscellaneous buttons and stuff.
This definitely leads to a jump-in-and-hack approach, unlike project sites where you end up clicking through a bunch of crap to get to the code. On Google Code, for instance, you have to click on the Source tab, then a tiny link somewhere on the page, and the code browser isn't even that good.
Hacked up code is all fine and good, but what I'm looking for are the tools that are necessary to make it easy to consume the code:
* Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.
* Accurate and complete API documentation (with bonus points for higher-level integration documentation.
* A bug tracking system
* Mailing lists.
These are all historically accepted best-practices that have (and continue) to serve the OSS community well, but they're also practices that are strongly and innately de-emphasized by github's "code first" UX.
If github (and git) were facilitating the production of marvelous new libraries and software that we'd never seen before, then maybe I'd acquiesce that it's worthwhile to abandon the best practices above.
That, however, has not been my experience. Most of the code is poorly maintained, often abandon-ware, and with unclear lineage. It's unknown which of the 50 forks is the best one to use at any given time, and what the ongoing costs will be to track unstable development branches directly, since there are no releases.
You make some important points. Let's go through that list and try to figure out how to make things better:
> Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.
When people do this on GitHub, the usual method is to create a release tag for each
version. GitHub offers tarballs of the repo at each version tag, and can quickly switch
views of the code.
I try to always use proper semantic versioning once my software reaches maturity, and I've never noticed GitHub getting in
the way of that.
> Accurate and complete API documentation (with bonus points for higher-level integration documentation.
There are a variety of Right Ways to do this, and it varies by language. In Haskell, for
example, the most popular form of API documentation is automatically generated from the
code and specially-formatted comments by Haddock. For other languages, there are various
competing ways of doing API docs, from writing the stuff manually up through a number of
doc extraction tools.
I think the ideal way for GitHub to handle this would be to introduce a separate docs
repo for each project, serve up the generated HTML, and put out some tools for updating
it. This is similar to what they do with project wikis.
This would require the cooperation of external tools to be easy, but the GitHub guys have
enough fame that they could probably start a flood of tools if they just get it started.
> A bug tracking system
GitHub has a rudimentary form of this, but it would be nice if they could insert
prominent links to external bug trackers, so people could use their favorite one. Barring
that, sticking a clearly-labeled link in the top-level readme file is a decent
approximation.
> Mailing lists.
Google Groups is a decent approximation of this. Again, it would be nice if there were a
standard way to insert links to external mailing list pages in GitHub projects.
the ideal way for GitHub to handle this would be
to introduce a separate docs repo for each project
In a GitHub project you can create a gh-pages branch. In this branch you can place HTML files that will get rendered at http://username.github.com/project-name/ ... This is automated by GitHub in the Admin tab of any project. Simply select the option GitHub Pages and it will generate a branch with a basic index.html for you, that also has a download link.
None of the projects are forked (at least as of now), but thee are quite a few people watching them. That's not really surprising, though, because it seems perfectly valid to watch a project while waiting for the first commit.
Google is still very committed to providing a great place to host open source projects at http://code.google.com/hosting, that has not changed. But many of us are also fans of GitHub, and recognize that there is a great community of developers there (particularly in the ruby community).
The Google account on GitHub has been setup simply as a place where some open source Google projects can be mirrored. As another commenter noted, this is actually one of the points of a DVCS.
"But many of us are also fans of GitHub, and recognize that there is a great community of developers there (particularly in the ruby community)", that's an interesting comment. Does Google care about Ruby?
While it doesn't get as much use as other languages internally, there certainly are a number of in-house projects that use it.
But more importantly, developers accessing our public APIs use Ruby. We maintain a number of client libraries to make accessing our APIs easier. (We also maintain similar libraries in Objective-C and C#, for example.)
What's the model for contributing patches going to look like? With GitHub projects, the usual method is to create a fork, do some work, and send in a pull request with a descriptive note. If it's easy to contribute, more people will do it; this is one of the big reasons why so many people are fans of GitHub.
Will contributing to the projects mirrored here be that easy?
This actually took longer than I expected to make it to the front page of Hn. I kind of wish it had waited until all of the repositories were filled out though.
So the google github account was started just a few days ago and is completely empty right now...and yet Githire ranks it as the "Top 1%" by estimated experience.
88 comments
[ 2.5 ms ] story [ 145 ms ] threadhttps://github.com/microsoft/
https://github.com/microsoft-dpe
https://github.com/Microsoft-Interop
https://github.com/WindowsAzure
I know! It would be horrible to have the service be free, and integrated with Google's other search and social features and therefore more visible to the world!
THE HORROR!!1
[edit: not to mention company lawyers looking to sue some NDA violating employees]
Perhaps you could grep for common libraries like "ffmpeg" and make a guess as to what sort of software it is. Maybe a video editor/player in the case of ffmpeg. Once you figure that out, you could show advertisements for the same sort of software.
So it's already free, it's already integrated into Google's search, if I want to be social about what I'm coding I can easily share it on G+...
What problems would be solved by doing anything differently?
If Google bought it and nothing changed I'd be happy!!! However, I don't think that'd be the case. Things would change and I suspect for the worse, since it's not a big cash cow like search is.
The biggest problem with google acquiring github is that github would be expected to integrate with google's infrastructure; which would be a monumental engineering task. I can't see that happening in any way that wouldn't hurt github somehow. The best case would be that months of github's engineering time is taken away from new features. The worst case is that github is integrated with google code somehow; which would probably result in a revolt by github's users.
I think an acquisition by google would only hurt the open source community. Google likes us too much to risk that.
I wouldn't be surprised if an acquisition is coming.
Remember: "optimizing for happiness".
founders => early 2 or 3 => next 10 => next 50
How much cash does Github have to keep the last 50 or the next 150 feeling special? This is where managing the business starts to get really hard.
I'd assume that the GH founders and first tier employees have probably each banked about $1M so far. A Google acquisition valued at $30-50M would set all of them up nicely and let them move on to other endeavors.
In my opinion, only a very generous profit sharing program or a planned acquisition strategy explains the complete lack of rogue employees blogging their gripes. Keep in mind all the drama at Twitter when it was small.
Maybe we just want to build an amazing company.
However, GH has always exceeded all of my expectations in every possible way, so good luck to you guys whatever path you choose.
Working for someone else's business doesn't fit into that model.
Right, and nothing says "unhappiness" like $100M or $200M.
Google Code is not going away, certainly. And I don't think Google has any real interest in GitHub: it's a product that would require such a large amount of retooling to work on Google's architecture that it would be cheaper to clone missing features into Google Code.
For private work I've been doing Google Code by far best matches our needs. (Your needs will be different.) One place we use Github and the other is Bitbucket. I really wish Google would take our money.
they'd have to start offering support - I think they don't like to
You might want to start that issue. Helps express a desire for the feature.
It's all mainly due to using git and its interface. Github has a great website design.
1. The code.
2. A descriptive readme, which GitHub has successfully trained people how to write.
3. Some miscellaneous buttons and stuff.
This definitely leads to a jump-in-and-hack approach, unlike project sites where you end up clicking through a bunch of crap to get to the code. On Google Code, for instance, you have to click on the Source tab, then a tiny link somewhere on the page, and the code browser isn't even that good.
Hacked up code is all fine and good, but what I'm looking for are the tools that are necessary to make it easy to consume the code:
* Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.
* Accurate and complete API documentation (with bonus points for higher-level integration documentation.
* A bug tracking system
* Mailing lists.
These are all historically accepted best-practices that have (and continue) to serve the OSS community well, but they're also practices that are strongly and innately de-emphasized by github's "code first" UX.
If github (and git) were facilitating the production of marvelous new libraries and software that we'd never seen before, then maybe I'd acquiesce that it's worthwhile to abandon the best practices above.
That, however, has not been my experience. Most of the code is poorly maintained, often abandon-ware, and with unclear lineage. It's unknown which of the 50 forks is the best one to use at any given time, and what the ongoing costs will be to track unstable development branches directly, since there are no releases.
> Stable, versioned releases, with sufficient API (if not ABI) compatibility across releases.
When people do this on GitHub, the usual method is to create a release tag for each version. GitHub offers tarballs of the repo at each version tag, and can quickly switch views of the code.
I try to always use proper semantic versioning once my software reaches maturity, and I've never noticed GitHub getting in the way of that.
> Accurate and complete API documentation (with bonus points for higher-level integration documentation.
There are a variety of Right Ways to do this, and it varies by language. In Haskell, for example, the most popular form of API documentation is automatically generated from the code and specially-formatted comments by Haddock. For other languages, there are various competing ways of doing API docs, from writing the stuff manually up through a number of doc extraction tools.
I think the ideal way for GitHub to handle this would be to introduce a separate docs repo for each project, serve up the generated HTML, and put out some tools for updating it. This is similar to what they do with project wikis.
This would require the cooperation of external tools to be easy, but the GitHub guys have enough fame that they could probably start a flood of tools if they just get it started.
> A bug tracking system
GitHub has a rudimentary form of this, but it would be nice if they could insert prominent links to external bug trackers, so people could use their favorite one. Barring that, sticking a clearly-labeled link in the top-level readme file is a decent approximation.
> Mailing lists.
Google Groups is a decent approximation of this. Again, it would be nice if there were a standard way to insert links to external mailing list pages in GitHub projects.
Any more problems or solutions?
See http://pages.github.com/ for more details.
The Google account on GitHub has been setup simply as a place where some open source Google projects can be mirrored. As another commenter noted, this is actually one of the points of a DVCS.
While it doesn't get as much use as other languages internally, there certainly are a number of in-house projects that use it.
But more importantly, developers accessing our public APIs use Ruby. We maintain a number of client libraries to make accessing our APIs easier. (We also maintain similar libraries in Objective-C and C#, for example.)
Not to mention that Sketchup uses Ruby for scripting: http://code.google.com/apis/sketchup/
Will contributing to the projects mirrored here be that easy?
If you still doubt it head your way to http://github.com/2394157ysajkfhkly5husdafjkasghf which produces an astoundingly familiar 404 message...
For the still confused, here is the quote: http://www.imdb.com/title/tt0076759/quotes?qt=qt0440731
and here is the clip: http://www.youtube.com/watch?v=vzcWPKAv2Ow
http://githire.com/profiles/google
That's some predictive algorithm it's got going