It was simply trying to prevent SF from becoming a shitty monoculture that hurt everyone, which it was when Google Code launched. Google was 100% consistent on this from the day it launched to the day it folded. It was not trying to make money, or whatever
I was there, working on it, when it was 4 of us :)
So to write all these funny things about taste or what not, is totally besides the point.
We folded it up because we achieved the goal we sought at the time, and didn't see a reason to continue.
People could get a good experience with the competition that now existed, and we would have just ended up cannibalizing the market.
So we chose to exit, and worked with Github/bitbucket/others to provide migration tools.
All of this would have been easy to find out simply by asking, but it appears nobody bothers to actually ask other people things anymore, and I guess that doesn't make as good a story as "we totally destroyed them because they had no taste, so they up and folded".
You sound like you're proud of this work and this plan and this sequence of events.
code.google going away, without the excuse that google itself was going away, after I had started to rely on it and link to it in docs and scripts all over the place, is what taught me to never depend on google for anything.
If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.
But Google did not say that. Google presented the service as a service whos purpose was to be useful to users. And only because of that, we used it.
Do you see the essential problem here? Effectively, Google harnessed users for it's own purposes without their consent by means of deception. The free-ness of the service that the users received doesn't even count as a fair trade in a transaction because the transaction was based on one party misinforming the other.
So thanks for all your work making the world a better place.
Incidentally, this is why I don't use any Google products other than search. It's never clear to me which ones are real products that are trying to win and make money, and which ones are just fun side projects that a multibillion dollar corporation is doing out of the goodness of their hearts, but could get shut down at any time.
All of this would have been easy to find out simply by asking
I'm not a journalist, but in an ideal scenario, how would somebody have known that you were one of the key members of the project?
It's not like Google (or anybody else) makes this easy to know. And call me jaded, but something tells me official Google PR channels would not have been really helpful for this.
And also - are most engineers in your sort of position even free to remark on such projects w.r.t. NDAs, etc?
I don’t see a contradiction; it’s all part of the story.
Understanding your (Google’s) motivations explains why Google Code didn’t improve as much. It doesn’t contradict that Github had better UI, or their explanation of their motivation to build a better UI.
If Google Code succeeded, it’s hard to imagine that Google would not have tried to monetize it someday.
This also reminds me of Google’s (also initial) position on Chrome vis-a-vis Firefox: create a product “not trying to make money, or whatever” but just to limit the market share of a competitor.
I'm not sure what "SF" means in this context. San Francisco? I can't figure out what you want to say Google Code was for exactly. If Google launches a major project, I find it hard to believe that it's just for fun.
Herein lies the tragedy. Google could've offered, even sold, its internal development experience (code hosting, indexing and searching, code reviews, build farms, etc...) which is and was amazing, but it decided that it wasn't worth doing and let GitHub eat its lunch.
I had this theory that generations raised on the internet and exposed to it from birth would be the most humble generations ever, because we all look for ways to be uniquely valuable, and it became nearly impossible to be egotistical when faced with the entirety of even just a mature youtube platform.
Instead what we got was higher degrees of selective attention, and very elaborate and obscure flip-cup tricks.
The only real tragedy here is that Google really did have best-of-industry semantic search integrated into their code searching tools, something that nobody has been able to replicate.
GitHub is great, but it's absolute ass for search. To the point where for any nontrivial question I have to pull down the repo and use command-line tooling on it.
> Actually, Google Code was never trying to win.
> It was simply trying to prevent SF from becoming a shitty monoculture that hurt everyone
Being an insider of Google might make one be completely out-of-touch of reality. Google Video was trying to prevent Youtube from becoming a shitty monoculture that hurt everyone, too? This one clearly failed then.
To be fair, you "lacking taste" and "not trying to win" are not mutually exclusive. You could argue they are respectively the proximate and ultimate cause for GitHub's win.
> It was simply trying to prevent SF from becoming a shitty monoculture that hurt everyone
Initially I thought SF means San Francisco, and I thought "Wow, what kind of monoculture can be prevented by Google Code", and then I realized that SF meant Source Forge.
This is a very bold statement, isn't it? So Google says the credit of making SourceForge (very deservedly) irrelevant is theirs and not GitHub's (or SourceForge themselves)?
As a complete nobody, why can't I think that in every example of a product launch, if it wins it wins, and if it fails, I can claim it was never intended to win?
Props for serving as primary source material. One of the reasons I, basically, no longer trust "tech" journalism.
Aside from too many hit/bait/paid-for pieces, writers have simply gotten "lazy" as they're no longer incentivized to "get it right"--just "get it out".
Granted, this post is, essentially, meant to be a whitepaper for their product offering, but c'mon guys, you had the references to reach out, but were lazy for...reasons?!
AWS also has a history of some of these "buit-to-marketize" products (e.g. CodeCommit), but at least there's a "solid core" of a stack to re-build these niche services from-scratch.
What's Google "reliable core" anymore aside from Compute Engine and Search? Don't get me started on Cloud SQL.
Whether Google wanted to win or not: Don't kid yourself into believing they _could_ have won even if they had tried. Google has a history of being terribly at executing on product ideas and Google Code never had the same "feel" that Github did.
There's a reason Microsoft paid billions for Github. If Google could have created that in-house themselves they would have done it.
Not saying Google tried and failed - they may just have realised that actually winning this was never an option.
This articles about the open source distribution side but I will also point out that the number of developers who don’t realise your remote GitHub repo can be located on any machine with an ssh connection and nothing more is surprising. As in people use private GitHub repos thinking that’s THE way you work with git. If GitHub was just for open source hosting I suspect they’d have trouble monetising like sourceforge clearly did which led to scammy attempts to make money. But they always had this huge usage of private GitHub repos supporting the rest. This must have helped a lot imho.
The celebrity of Linus definitely helped Git win, and GitHub likely benefited from that by the name alone. Many people today mistakenly equate Git and GitHub, and since GH did such a good job of being a friendly interface to Git, to many people it _is_ Git. They did an early bet on Git alone, at a time when many of its competitors were supporting several VCSs. That early traction set the ball rolling, and now everyone developing in public pretty much has to be on it.
Tangentially: it's a pretty sad state of affairs when the most popular OSS hosting service is not only proprietary, but owned by the company who was historically at opposite ends of the OSS movement. A cynic might say that they're at the extend phase of "embrace, extend, extinguish". Though "extinguish" might not be necessary if it can be replaced by "profit" instead.
GitHub won because Git won. It was obvious by the late 00s that some DVCS was going to upend subversion (and more niche VCS like TFS). It ended up a two horse race between Git and Mercurial. GitHub bet on Git. Bitbucket bet on Mercurial.
Git took the early lead and never looked back. And GitHub's competitors were too slow to embrace Git. So GitHub dominated developer mindshare.
It seems strange now but there was a period of time during the late 00s and early 10s when developers were pretty passionate about their choice of DVCS.
Thank you for sharing this, Scott! He mentions "Taste" throughout the post and this intangible quality makes all the difference in an early-stage winner-take-all market dominance race.
In 2007 I was teaching myself programming and had just started using my first version control tools with Mercurial/Hg after reading Joel Spolky's blog post/love letter to Mercurial. A year or two later I'd go to user group meetups and hear many echo my praise for Hg but lamenting that all the cool projects were in GitHub (and not bitbucket). One by one nearly everyone migrated their projects over to git almost entirely because of the activity at GitHub. I even taught myself git using Scott's website and book at that point!
"Product-market fit" is the MBA name for this now. As Scott elegantly states this is mostly knowing what problem you solve, for whom, and great timing, but it was the "flavor" of the site and community (combined with the clout of linux/android using git) that probably won the hearts and minds and really made it fit with this new market.
Edit: It didn't hurt that this was all happening at the convergence of the transition to cloud computing (particularly Heroku/AWS), "Web 2.0"/public APIs, and a millennial generational wave in college/first jobs-- but that kinda gets covered in the "Timing, plus SourceForge sucked" points
I used both GitHub and BitBucket during the early days. There was no comparison. GitHub was simply nice to use. The UX was phenomenal for its time and made sense. BitBucket was horrible but my then employer wouldn’t pay for hosting and GitHub didn’t provide free private hosting.
One of my biggest gripes was that switching back and forth between code view and editor mode would wipe whatever you had written. So you better had them in separate tabs. Also be sure not to press the backspace key outside a text window.
As a "younger" programmer it always shocks me how things like git were only created in 2005. It feels so ubiquitous and the way it functions has the "feeling" of something created in the 80s or 90s to me.
The idea of Github having a unique "taste" advantage resonates with me a lot. I don't like the fact that Github is using my code to feed Microsoft's AI ambitions, but I dislike Bitbucket and Gitlab more simply on the grounds that they "don't look fun".
It's tricky, because any serious Github competitor would implicitly have to compete by attracting the deep pockets of enterprise clients, who care little for "fun". Getting revenue from solo devs / small teams is an uphill battle, especially if you feel obliged to make your platform open source.
Still, I wish someone would make a Github competitor that's fun and social.
This article reinforces a lot of my biases around early bets. Taste is so so important, everyone looks at you weird when you say you're betting on "niche, tasteful solution" (git) instead of "common, gross solution" (SVN). Github bet on Git and made tasteful choices, and that was a huge propellant for them.
I feel the same way about tscircuit (my current startup), it's a weird bet to create circuit boards with web technologies, nobody really does it, but the ergonomics _feel better_, and I just have to trust my taste!
fundamentally interesting thing that I think showed in everything that we did was that we built for ourselves. We had taste. We cared about the experience.
The "taste" thing is weird, making an analogy with Apple vs. Microsoft, who explicitly competed at many times
As DannyBee said, there was never any Google vs. Github competition, because Google's intention was never to build something like Github
In fact, one thing he didn't mention is that URL, as I recall, was
code.google.com/hosting/
not
code.google.com/ # this was something ELSE, developer API docs for maps, etc.
SPECIFICALLY because management didn't want anyone to think it was a product. It was a place to put Google's own open source projects, and an alternative to SourceForge. (There was also this idea of discouraging odd or non-OSS licenses, which was maybe misguided)
That is, the whole project didn't even deserve its own Google subdomain !!! (according to management)
(I worked on Google Code for around 18 months)
---
However if I try to "steel man" the argument, it's absolutely true that we didn't use it ourselves. The "normal" Google tools were used to build Google Code, and we did remark upon that at the time: we don't dogfood it, and dogfooding gives you a better product
But it was a non-starter for reasons that have to do with Google's developer and server infrastructure (and IMO are related to why Google had a hard time iterating on new products in general)
I think also think Github did a lot of hard work on the front end, and Google famously does not have a strong front end culture (IMO because complex front ends weren't necessary for the original breakout product of search, unlike say Facebook)
I think the analysis is largely correct. But not entirely. My take on this is that 1) Github fixed the one problem that Git had: terrible UX. Github made it more like subversion. Enough so to consider switching. Indeed a lot of small companies treat it like a central repository with commit rights for everyone. 2) It fixed a big problem OSS projects had: it was very hard to contribute to them.
The first reason was why Git became interesting, the second one is why it won.
Prior to Github the way to contribute to OSS projects was a protracted process of engaging with very busy people via mailing lists, issue trackers, and what not and jumping through a lot of hoops to get your patches considered, scrutinized, and maybe merged. If you got good at this, you might eventually earn commit privileges against some remote, centralized repository. This actively discouraged committing stuff. OSS was somewhat elitist. Most programmers never contributed a single line of OSS code or even considered doing so.
Github changed all that. You could trivially fork any project and start tinkering with it. And then you could contribute your changes back with a simple button push: create pull request. It actively encouraged the notion. And lots of people did.
Github enabled a bunch of kids that were into Ruby to rapidly scale a huge OSS community that otherwise would not have existed. That success was later replicated by the Javascript community; which pretty much bootstrapped on Github as well. What did those two communities have in common: young people who were mostly not that sophisticated with their command line tooling. This crowd was never going to be exchanging patches via some mailing list, like the Linux crowd still does today. But they could fork and create pull requests. And they did. Both communities had a wild growth of projects. And some of them got big.
Github gave them a platform to share code so they all used it. And the rest is just exponential growth. Github rapidly became the one place to share code. Even projects with their own repositories got forked there. Because it was just easier. A lot of those projects eventually gave up on their own central infrastructure. Accepting contributions via Github was easier. In 2005 Git was new and obscure; very elitist. In 2008 Github popped up. By 2012 it hosted most of the OSS community. Game over by around 2010 I would guestimate. By 2015 even the most conservative shops were either using it or considering it at least.
Another big advantage of Git for sites like GitHub is that you are never putting your eggs into one basket. You have your local copy of all history in a project. GitHub is merely a mirror. Sure, some features have been sprinkled on top like pull requests and an issue tracker, but those are not the most critical part. If GitHub goes down you can move your whole Git history to another site like GitLab, sourcehut, or just self-host it, or you can even start doing it right now with minimal effort. This was never the case with CVS and Subversion.
Man, given how terrible GitHub's developer workflow is in 2024... there is still no first-class support for stacked diffs, something that Phabricator had a decade ago and mailing list workflows have been doing for a very long time.
I personally treat GH as a system that has to be hacked around with tools like spr [1], not a paragon of good developer workflows.
I professionally used RCS, CVS, Subversion and Perforce before Git came along. Hell, I was actually in a company that FTP'd it's PHP files directly to the production server.
People in the field less than 20 years might not appreciate the magnitude of this change (though, adding my two cents to the author's article, branching in p4 was fine). People may have also dealt with ClearCase (vobs!) or Microsoft Visual SourceSafe.
Git did as much for software development velocity as any other development in recent history.
Around about that time, I was working on a Mercurial frontend https://github.com/tanepiper/hgfront - it was around the time GitHub was starting to pick up, and BitBucket also appeared around then (we spoke to the original developer at the time but nothing came of it). Funnily enough also a Gist-like tool that had inline commenting, forking and formatting (https://github.com/tanepiper/pastemonkey).
I always wonder what would have happened if we had a dedicated team to make something of it, but in the end git won over hg anyway so likely a moot point.
> one of the Linux developers reverse engineered the protocol, breaking the licensing terms
Tridge never accepted the license terms of BitKeeper and re-implemented client libraries only by observing black box behaviour of the server, so at no point did he break the terms of the license. He also told Linus what he was doing and asked, "how do you think [Larry McVoy] will react?". Linus said he thought it would be okay.
I clicked on this link thinking "timing and product quality", so I was satisfied to see that GitHub co-founder Scott Chacon credits it to "GitHub started at the right time" and "GitHub had good taste".
I don't think that GitHub is the most popular forge because it is _good_. I have never heard anyone say "I use GitHub because it has a good UI", "... has good accessibility", "... is well designed", "... I prefer proprietary services" or anything remotely similar.
The main reason I hear people say they use GitHub is due to network effect. "It's what everyone else is using", "You'll get more visibility and more contributions" or "My employer forces us to use it".
Essentially, the same reasons why Windows is a popular platform; not really technical reasons, mostly business and ecosystem factors driving people towards it.
Sure, GitHub was* better than the alternative in its initial days. But things have changed in the last decade. GH has continuously declined while alternatives have surfaced and improved dramatically.
Personally, it pisses me that GitHub presents itself as "an open source hub", when it is a proprietary, hosted, service.
I wonder if there's an alternative universe where Fog Creek pushed Kiln - their hosted Mercurial product - harder and exploited the mindshare of Stack Overflow somehow. Perhaps if they'd tried to get open source projects and their maintainers onto a shared platform to manage both code and (potentially paid) support they would have earned a mention here.
[+] [-] DannyBee|1 year ago|reply
It was simply trying to prevent SF from becoming a shitty monoculture that hurt everyone, which it was when Google Code launched. Google was 100% consistent on this from the day it launched to the day it folded. It was not trying to make money, or whatever
I was there, working on it, when it was 4 of us :)
So to write all these funny things about taste or what not, is totally besides the point.
We folded it up because we achieved the goal we sought at the time, and didn't see a reason to continue.
People could get a good experience with the competition that now existed, and we would have just ended up cannibalizing the market.
So we chose to exit, and worked with Github/bitbucket/others to provide migration tools.
All of this would have been easy to find out simply by asking, but it appears nobody bothers to actually ask other people things anymore, and I guess that doesn't make as good a story as "we totally destroyed them because they had no taste, so they up and folded".
[+] [-] Brian_K_White|1 year ago|reply
code.google going away, without the excuse that google itself was going away, after I had started to rely on it and link to it in docs and scripts all over the place, is what taught me to never depend on google for anything.
If google had said "The purpose of this service is an academic goal of Googles, not to serve users needs. This service will be shut off as soon as Googles academic purpose is met." I would not have used it.
But Google did not say that. Google presented the service as a service whos purpose was to be useful to users. And only because of that, we used it.
Do you see the essential problem here? Effectively, Google harnessed users for it's own purposes without their consent by means of deception. The free-ness of the service that the users received doesn't even count as a fair trade in a transaction because the transaction was based on one party misinforming the other.
So thanks for all your work making the world a better place.
[+] [-] defen|1 year ago|reply
[+] [-] JohnBooty|1 year ago|reply
It's not like Google (or anybody else) makes this easy to know. And call me jaded, but something tells me official Google PR channels would not have been really helpful for this.
And also - are most engineers in your sort of position even free to remark on such projects w.r.t. NDAs, etc?
[+] [-] skybrian|1 year ago|reply
Understanding your (Google’s) motivations explains why Google Code didn’t improve as much. It doesn’t contradict that Github had better UI, or their explanation of their motivation to build a better UI.
[+] [-] jonathanyc|1 year ago|reply
If Google Code succeeded, it’s hard to imagine that Google would not have tried to monetize it someday.
This also reminds me of Google’s (also initial) position on Chrome vis-a-vis Firefox: create a product “not trying to make money, or whatever” but just to limit the market share of a competitor.
The less flattering term for this in the context of anticompetitive behavior is “dumping”: https://en.wikipedia.org/wiki/Dumping_(pricing_policy)
[+] [-] schacon|1 year ago|reply
[+] [-] ThrowawayR2|1 year ago|reply
Wasn't Google reported among the bidders for GitHub?
https://www.cnbc.com/2018/06/05/github-interest-from-google-...
Maybe Google Code itself was never trying to win but tendering an significant offer to the auction suggests Google was trying to win something.
[+] [-] osmsucks|1 year ago|reply
Herein lies the tragedy. Google could've offered, even sold, its internal development experience (code hosting, indexing and searching, code reviews, build farms, etc...) which is and was amazing, but it decided that it wasn't worth doing and let GitHub eat its lunch.
[+] [-] svnt|1 year ago|reply
Instead what we got was higher degrees of selective attention, and very elaborate and obscure flip-cup tricks.
[+] [-] shadowgovt|1 year ago|reply
GitHub is great, but it's absolute ass for search. To the point where for any nontrivial question I have to pull down the repo and use command-line tooling on it.
[+] [-] meiraleal|1 year ago|reply
[+] [-] olalonde|1 year ago|reply
[+] [-] Jyaif|1 year ago|reply
In 2018, MS bought Github for 7B.
Google Code started to be shutdown mid-2015. In 2015 it wasn't clear yet that it would be valuable for Google to host the world's code?
[+] [-] hintymad|1 year ago|reply
Initially I thought SF means San Francisco, and I thought "Wow, what kind of monoculture can be prevented by Google Code", and then I realized that SF meant Source Forge.
[+] [-] theanonymousone|1 year ago|reply
As a complete nobody, why can't I think that in every example of a product launch, if it wins it wins, and if it fails, I can claim it was never intended to win?
[+] [-] calmbonsai|1 year ago|reply
Aside from too many hit/bait/paid-for pieces, writers have simply gotten "lazy" as they're no longer incentivized to "get it right"--just "get it out".
Granted, this post is, essentially, meant to be a whitepaper for their product offering, but c'mon guys, you had the references to reach out, but were lazy for...reasons?!
AWS also has a history of some of these "buit-to-marketize" products (e.g. CodeCommit), but at least there's a "solid core" of a stack to re-build these niche services from-scratch.
What's Google "reliable core" anymore aside from Compute Engine and Search? Don't get me started on Cloud SQL.
[+] [-] sqren|1 year ago|reply
Not saying Google tried and failed - they may just have realised that actually winning this was never an option.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] sqren|1 year ago|reply
Github beat basically every Code hosting platform out there. Probably dusins of Github-like startups tried and failed because Github did so well.
So whether Google Code "wanted to win" or not doesn't really take away anything from the posts argument that Github won due to timing and taste.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] authorfly|1 year ago|reply
raises eyebrow
When there were 4 of you?
So about $800k a year for that time period?
Just out of interest?
[+] [-] cynicalpeace|1 year ago|reply
[deleted]
[+] [-] gerdesj|1 year ago|reply
[deleted]
[+] [-] franciscop|1 year ago|reply
[deleted]
[+] [-] BSDobelix|1 year ago|reply
First: That sounds completely not like Google
Second: Now you have GH as the "shitty monoculture" (owner is MS and erases your license for Co-pilot)
Third: >>We folded it up because we achieved the goal we sought at the time, and didn't see a reason to continue.
Yeah ok that sounds like Google, try's to enter another market just to hurt them then folds ;)
[+] [-] shawabawa3|1 year ago|reply
If you were never trying to win, that's a product failure
You should have been trying to win, you should have built a strong competitor to GitHub and you shouldn't have let it rot until it was shut down
The world would have been a better place if Google code tried to be as good as GitHub
[+] [-] AnotherGoodName|1 year ago|reply
https://news.ycombinator.com/item?id=31110206
This articles about the open source distribution side but I will also point out that the number of developers who don’t realise your remote GitHub repo can be located on any machine with an ssh connection and nothing more is surprising. As in people use private GitHub repos thinking that’s THE way you work with git. If GitHub was just for open source hosting I suspect they’d have trouble monetising like sourceforge clearly did which led to scammy attempts to make money. But they always had this huge usage of private GitHub repos supporting the rest. This must have helped a lot imho.
[+] [-] imiric|1 year ago|reply
Tangentially: it's a pretty sad state of affairs when the most popular OSS hosting service is not only proprietary, but owned by the company who was historically at opposite ends of the OSS movement. A cynic might say that they're at the extend phase of "embrace, extend, extinguish". Though "extinguish" might not be necessary if it can be replaced by "profit" instead.
[+] [-] nerdix|1 year ago|reply
Git took the early lead and never looked back. And GitHub's competitors were too slow to embrace Git. So GitHub dominated developer mindshare.
It seems strange now but there was a period of time during the late 00s and early 10s when developers were pretty passionate about their choice of DVCS.
[+] [-] ldayley|1 year ago|reply
In 2007 I was teaching myself programming and had just started using my first version control tools with Mercurial/Hg after reading Joel Spolky's blog post/love letter to Mercurial. A year or two later I'd go to user group meetups and hear many echo my praise for Hg but lamenting that all the cool projects were in GitHub (and not bitbucket). One by one nearly everyone migrated their projects over to git almost entirely because of the activity at GitHub. I even taught myself git using Scott's website and book at that point!
"Product-market fit" is the MBA name for this now. As Scott elegantly states this is mostly knowing what problem you solve, for whom, and great timing, but it was the "flavor" of the site and community (combined with the clout of linux/android using git) that probably won the hearts and minds and really made it fit with this new market.
Edit: It didn't hurt that this was all happening at the convergence of the transition to cloud computing (particularly Heroku/AWS), "Web 2.0"/public APIs, and a millennial generational wave in college/first jobs-- but that kinda gets covered in the "Timing, plus SourceForge sucked" points
[+] [-] max_|1 year ago|reply
Just people/products that are temporarily on top.
SourceForge was probably "the winner" for some time.
The same will be for GitHub.
Someone just needs to build an actual superior product and provide a service that GitHub will not provide. Then build a sufficient audience.
One such service is an end to end encrypted Git repo service.
Some anarchists I know don't want everyone to know what they are working on.
The same goes for algorithmic trading. I need strong guarantees that my code will not be used to train an LLM that will leak my edge.
I am shocked a superior Git service to GitHub has not been built.
I really liked source hut. But the custodian is abit arrogant (crypto projects for instance are banned)
[+] [-] crop_rotation|1 year ago|reply
I doubt there is a big enough market of anarchists for Github to even bother worrying.
> One such service is an end to end encrypted Git repo service.
There are so few people that need this, that they can just use client side tools and store all data that gets to remote servers encrypted
[+] [-] SenHeng|1 year ago|reply
One of my biggest gripes was that switching back and forth between code view and editor mode would wipe whatever you had written. So you better had them in separate tabs. Also be sure not to press the backspace key outside a text window.
[+] [-] teqsun|1 year ago|reply
[+] [-] Bjorkbat|1 year ago|reply
It's tricky, because any serious Github competitor would implicitly have to compete by attracting the deep pockets of enterprise clients, who care little for "fun". Getting revenue from solo devs / small teams is an uphill battle, especially if you feel obliged to make your platform open source.
Still, I wish someone would make a Github competitor that's fun and social.
[+] [-] seveibar|1 year ago|reply
I feel the same way about tscircuit (my current startup), it's a weird bet to create circuit boards with web technologies, nobody really does it, but the ergonomics _feel better_, and I just have to trust my taste!
[+] [-] chubot|1 year ago|reply
The "taste" thing is weird, making an analogy with Apple vs. Microsoft, who explicitly competed at many times
As DannyBee said, there was never any Google vs. Github competition, because Google's intention was never to build something like Github
In fact, one thing he didn't mention is that URL, as I recall, was
not SPECIFICALLY because management didn't want anyone to think it was a product. It was a place to put Google's own open source projects, and an alternative to SourceForge. (There was also this idea of discouraging odd or non-OSS licenses, which was maybe misguided)That is, the whole project didn't even deserve its own Google subdomain !!! (according to management)
(I worked on Google Code for around 18 months)
---
However if I try to "steel man" the argument, it's absolutely true that we didn't use it ourselves. The "normal" Google tools were used to build Google Code, and we did remark upon that at the time: we don't dogfood it, and dogfooding gives you a better product
But it was a non-starter for reasons that have to do with Google's developer and server infrastructure (and IMO are related to why Google had a hard time iterating on new products in general)
I think also think Github did a lot of hard work on the front end, and Google famously does not have a strong front end culture (IMO because complex front ends weren't necessary for the original breakout product of search, unlike say Facebook)
[+] [-] jillesvangurp|1 year ago|reply
The first reason was why Git became interesting, the second one is why it won.
Prior to Github the way to contribute to OSS projects was a protracted process of engaging with very busy people via mailing lists, issue trackers, and what not and jumping through a lot of hoops to get your patches considered, scrutinized, and maybe merged. If you got good at this, you might eventually earn commit privileges against some remote, centralized repository. This actively discouraged committing stuff. OSS was somewhat elitist. Most programmers never contributed a single line of OSS code or even considered doing so.
Github changed all that. You could trivially fork any project and start tinkering with it. And then you could contribute your changes back with a simple button push: create pull request. It actively encouraged the notion. And lots of people did.
Github enabled a bunch of kids that were into Ruby to rapidly scale a huge OSS community that otherwise would not have existed. That success was later replicated by the Javascript community; which pretty much bootstrapped on Github as well. What did those two communities have in common: young people who were mostly not that sophisticated with their command line tooling. This crowd was never going to be exchanging patches via some mailing list, like the Linux crowd still does today. But they could fork and create pull requests. And they did. Both communities had a wild growth of projects. And some of them got big.
Github gave them a platform to share code so they all used it. And the rest is just exponential growth. Github rapidly became the one place to share code. Even projects with their own repositories got forked there. Because it was just easier. A lot of those projects eventually gave up on their own central infrastructure. Accepting contributions via Github was easier. In 2005 Git was new and obscure; very elitist. In 2008 Github popped up. By 2012 it hosted most of the OSS community. Game over by around 2010 I would guestimate. By 2015 even the most conservative shops were either using it or considering it at least.
[+] [-] gsliepen|1 year ago|reply
[+] [-] sunshowers|1 year ago|reply
Man, given how terrible GitHub's developer workflow is in 2024... there is still no first-class support for stacked diffs, something that Phabricator had a decade ago and mailing list workflows have been doing for a very long time.
I personally treat GH as a system that has to be hacked around with tools like spr [1], not a paragon of good developer workflows.
[1] my fork with Jujutsu support: https://github.com/sunshowers/spr
[+] [-] throwaway5752|1 year ago|reply
People in the field less than 20 years might not appreciate the magnitude of this change (though, adding my two cents to the author's article, branching in p4 was fine). People may have also dealt with ClearCase (vobs!) or Microsoft Visual SourceSafe.
Git did as much for software development velocity as any other development in recent history.
[+] [-] tanepiper|1 year ago|reply
I always wonder what would have happened if we had a dedicated team to make something of it, but in the end git won over hg anyway so likely a moot point.
Edit: there's a low-quality video of the early interface we worked on - https://youtu.be/NARcsoPp4F8
[+] [-] grifferz|1 year ago|reply
Tridge never accepted the license terms of BitKeeper and re-implemented client libraries only by observing black box behaviour of the server, so at no point did he break the terms of the license. He also told Linus what he was doing and asked, "how do you think [Larry McVoy] will react?". Linus said he thought it would be okay.
https://lwn.net/Articles/969221/
[+] [-] simonw|1 year ago|reply
[+] [-] WhyNotHugo|1 year ago|reply
The main reason I hear people say they use GitHub is due to network effect. "It's what everyone else is using", "You'll get more visibility and more contributions" or "My employer forces us to use it".
Essentially, the same reasons why Windows is a popular platform; not really technical reasons, mostly business and ecosystem factors driving people towards it.
Sure, GitHub was* better than the alternative in its initial days. But things have changed in the last decade. GH has continuously declined while alternatives have surfaced and improved dramatically.
Personally, it pisses me that GitHub presents itself as "an open source hub", when it is a proprietary, hosted, service.
[+] [-] thom|1 year ago|reply