It's just not that important. I'm just one guy without a steady job, and even I can cough up $7/mo for a Micro account. I'd much much rather have GitHub's gorgeous interface than BitBucket's.
If your business can't afford $25/month, then you don't have a business.
It may be $7/mo, but you only get 5 private repos and one collaborator. If you want more than a small handful of private projects, or even want to work on a private project with another person you need to cough up $12/mo, which is infeasable for just a hobby project or two.
BitBucket, on the other hand, gives you unlimited public and private repositories and 5 collaborators for /free/.
For a business, $25/mo isn't much, but for personal projects i prefer free over paid.
Are you kidding me?; for private stuff I use a shared hosting service with shell access for $35 a year, unlimited repos and contributors. And I even host a well visited wiki on that server.
Anything else that involves other people and is private is somewhat of ant oxymoron. And for OSS like stuff there are more than enough services on github in the free plan.
Even if $7-12/mo is peanuts to you (it definetly isn't to me), it's still $ vs free. And even comparing bitbucket's free plan vs github's $12 plan, bitbucket's /still/ provides more value.
As for if github is so much better as to be worth the extra money is an entirely different flamew..discussion.
We're glad to hear that you're enjoying Bitbucket's unlimited repositories.
Many others have been surprised by our move to allow unlimited private repositories... unlimited repositories is something we're happy to give back to the development and open-source community. This approach is similar to our Starter licenses, which are fully featured versions of our products for $10, for up to 10 users. All of the proceeds go to our favorite charity Room to Read.
To date, we've donated $750k USD to build schools and provide children with scholarships in places like Cambodia so they can complete high school.
Starter licenses are used by millions of developers around the globe, but they had one missing bit. The ability to store your code somewhere -- something every developer needs.
Building on the success of Starter licenses, we've modeled the Bitbucket pricing in the same way -- to help open-source, up-and-coming developers and organizations get their ideas started hassle free.
Be rest assured, our Starter licenses and Bitbucket's unlimited private repositories are here to stay.
The only bad thing about your switch to the free plan, from my perspective, is that I no longer could justify paying for anything. Hey, it's great that you want to give me the service I want for free :) but I never really begrudged that $12 a month.
We compete against BitBucket's free plan by providing better service & features, a much larger community, and an insane amount of publicly available code.
It came as no surprise to us when Atlassian decided the only way BitBucket could compete with GitHub was to essentially give it away.
While they can afford to do this now, I'm fearful that the people choosing BitBucket for this reason alone may get a rude awakening when Atlassian decides BitBucket shouldn't continue being a loss-leader for the rest of their products.
Our growth at GitHub has only continued to increase month over month, so while people laud BitBucket's free plan, many more understand the value of paying for a premium service.
I don't begrudge you for using BitBucket because you prefer Mercurial, but your original response only had to do with the cost of the service which is why I felt compelled to respond. Thanks for the kind words about GitHub.
I suspect I'm a minority, but I miss the old days of "download a tgz, make a change, mail the author a patch". There's a lot of effort involved in cloning (then discovering I need to fork first, then clone my fork), and somehow communicating my change to the author.
I think this has a lot to do with UI. Even after a few attempts at this, I still can't find the various buttons when I want to. For example, there's a pull requests tab on the original repo and on my fork plus another button somewhere above that. Which do I click when?
This is on top of the fact I'm rarely sure if I'm working on the "real" repo or some random dude's copy.
Note I don't dislike DVCS. I like it a lot. But if you don't read the right blogs or wherever it is the cool kids figure out which repos are active and which aren't, the github centric experience is frustrating.
1. The fork button is a lot smaller than the git clone url staring right up at me in the middle of the page.
6. Which pull request button on which page? There are several.
Yes, I've done this a few times. But the procedure is not internalizable in the same way that "mail patch" is. In particular, the pull requests tab always looks really appealing to me whenever I want to clone a new repo (I'd like to make a request to pull your source, after all). The problem is unrelated to git, I could happily use git with email.
Yep, I think this is just a preferences thing. The bug "Pull request" tab implies to me that they're pull requests that are currently pending, since it's in amongst the source, the issues... and since it's a tab. The button implies "start a pull request for upstream" since it's up near several other 'action' buttons.
Yeah, that's twice as many steps as "email the author a patch." But you're right, there's still nothing keeping you from emailing the author a patch (I've contributed to github-hosted projects that way).
This is mostly first time setup. After you've done it, it becomes "Commit, type git push, click pull request." Same as "Commit, type 'git format-patch', send email."
> But if you don't read the right blogs or wherever it is the cool kids figure out which repos are active and which aren't, the github centric experience is frustrating.
True, Github badly needs a "bless this non-root repository as the canonical one" feature. That's absolutely important for less plugged-in contributors, which may be why it's not as high on their radar.
IMO, the problem with GitHub is the community. For some reason the Ruby community rubs me the wrong way, in a way that the Java, Python, Lisp communities don't.
While I can respect Ruby and RoR technically, it's not so far above other products that it can make up for the fact that I'd prefer not to interact with the community on a day to day basis.
Maybe I've just hit a weird sample, but I've heard other people outside of my circle make similar comments, yet I've rarely, if ever, heard it said about other communities (except maybe the Slashdot community).
I don't have the data in front of me, but if JS is #1, Ruby can't be far behind. And while I completely believe you, it still feels to me more like a Ruby/Rails community than it does a JS community.
That's because it's not a community based on language use, it's a community based on code sharing via a specific source control engine + community/social features + project management features.
github has to be one of the few services/companies that use ruby that doesn't constantly push it in your face with a bunch of better-than-thou blog posts about how ruby is awesome. Twitter used to be like that (or at least felt like it) with ruby/rails and then eventually with whatever language or technology du jour they were using.
None of my github projects are ruby, and I don't think many of the projects I follow are ruby (I honestly don't really keep track of that, but it would be an interesting statistic).
While I know github uses ruby, I don't think of them as doing anything other than providing the github service/website. In the same way I don't really think of Facebook as anything other than providing the facebook service/website. It only comes up when we talk about hiring ("If you want to work at Facebook, you'd have to do PHP.") or when you get a fatal error (I actually got "Fatal error: Uncaught OAuthException: An active access token must be used to query information about the current user. thrown in /var/www/publisher/system/application/libraries/facebook.php on line 453" the other day -- that's only happened once for me). I'd like to think that some places concentrating on providing a good service/experience and the actual choice of implementation only matters to them and they'd use the best tools for the job (where "best" may be defined as amount of experience they have with it).
Consider the perception of the language agnostic nature of github vs codeplex. I don't spend a lot of time on codeplex, but I have this perception that just about everything hosted on codeplex is written in one of the limited subset of languages that Microsoft sanctions/supports (this may be a function of the Microsoft/Windows platform, where it's non-trivial to get things like, say, vanilla ruby or python running on Windows compared to .Net stuff). Code that is hosted on github is merely known to use git for source control.
>MO, the problem with GitHub is the community. For some reason the Ruby community rubs me the wrong way
While I get that same feel from the rubbings from some ruby folk, (I'm a C/python/Objective C guy mainly), I don't honestly feel their rubbings in relation to github at all. I mean, it's source control, what does it have to do with the language you put into it?
Are you rejecting git too because rubyiests happen to use grabbed onto Linus Torvald's version of Hg?
While I get that same feel from the rubbings from some ruby folk, (I'm a C/python/Objective C guy mainly), I don't honestly feel their rubbings in relation to github at all. I mean, it's source control, what does it have to do with the language you put into it?
As the author of the original blog entry stated, feature-wise Git is similar to many other source control systems, "The issue wasn't the technology. Mercurial and Git are pretty much at feature parity (as is Bazaar)."
He goes on to say that the differentiator is the community. If the source control system isn't technologically superior to other competing technologies, and the community is the differentiating factor, but the community is one that I'm not extremely enamored with, wouldn't I be wise to stay away?
Maybe what you're saying is that in fact the community is not that important with repect to GitHub. It's a web front end for source control and it's really good, period. In that case, maybe it's worth another look. Although again, pretty much the only people I hear talking about GitHub are Ruby folks, and most of what they talk about is how GitHub is great because of the Ruby community.
I didn't even catch that in the original article which I did read. Your comment makes much more sense.
Having used Hg and git, I do not feel they're equivalent. I feel Hg is quite a bit more friendly to new folks, however git is considerably more powerful feeling to moderately good folks. I'm honestly a little sad python people are so enamored with Hg :o(
Honestly, the "Your repo can be marked public or private" thing gives me the willies. I prefer offerings which don't support public status, so you never accidentally dump your codebase onto the internet. But if you are doing something open source, it fantastic.
"The main reason is that at this point, BitBucket is simple attempting to feature copy from Github except using Mercurial in the background."
I am so tired to read things like that.
Issue-tracking at github is far behind bitbucket issue tracking (try to make complex search queries... you cannot link a commit to an issue except when closing the issue... tags are nice, but i dislike having to create a tag for each milestone/release).
Wikis at Github have only been recently backed by a git repository: as far as I know, wikis at bitbucket have always been backed by a mercurial repository.
It's true that bitbucket is a lot like github and that github has a bigger and more dynamic community (from my experience, github's infrastructure is also faster), but can we leave bitbucket alone and stop the bashing?
> Mercurial and Git are pretty much at feature parity (as is Bazaar).
Someone hasn't tried to use bzr on a nontrivial project. Half the threads on the emacs-devel mailing list are either complaining about bzr or asking for help because it's misbehaving. (The people who aren't complaining are the ones using the git mirror.)
The one question that bothers me is confidentiality.... code is IP of the company writing it. What prevents someone on a copyright fishing expedition from getting some kind of court order for the hosting provider to turn over all of my company's code without even telling me? It's the same argument for all hosted services.
For open development, it's awesome... closed - I wish so many saas providers offered self-hosted solutions with a subscription so I could at least control the hardware & it's location.
Except, their pricing starts at $2,500 per year for 10 devs. Holy shit.
I'll bet they sell scads of it to companies with more money than they know what to do with, but that seems crazy to me. As wonderful as github is, it's still just source control.
Seems totally reasonable to me. That's not that much money for an actual business expense. If you have such Super Ultra Secrets that they Must Be Kept On Your Servers, or else The World Breaks!!!!1, then you can afford to pay good money to keep it safe. I'd argue that it's still pretty cheap. Compared to ten salaries?
Super-ultra-secrets has nothing to do with it (though if you're a small shop, pointing the finger at github if/when confidential stuff flies the coop isn't going to go over well with certain clients).
My code (and other assets) are important to me; if it ends up on a torrent server in china, that's bad. Github's security is better than mine, but I'm not a honeypot either. Perhaps the formal probabilities are against me; I guess I'm irrational in a few ways.
Color me a little disappointed that this article wasn't about the fact that GitHub's roaring success has watered down everyone's enthusiasm for git's decentralized model. People keep asking you to use GitHub, in part, because they aren't setting up their own git servers, although they could - and one could argue that the future's a little safer with people keeping a bit of control.
If you've ever run your own git server (and I do), you have to pretty much setup something like gitosis or other solutions to manage the new projects....or you have to ssh in to make new projects.
I see absolutely no more than an afternoon's work to take people's work and move to a completely different remote central repo if github were to vanish from the internet one day.
The central node is a lot easier. git is not a source control system. It is a system for making a source control system. For many people, the centralized system is great.
Paranoid thought: An "evil" service like this could handily take a look at promising private projects, right? I guess that if your company becomes too innovative you would not risk that innovation by putting it in somebody else's server. Or would you?
Edit: My question goes along the same lines as dedward's.
github has been profitable for a while now because of people like me who give them money for a great service. If something like this happened, they would stop being profitable.
It's hard to imagine what they'd find in a private repo that would make them more money than what they've got in https://github.com/github
So for the small development workshops (i.e. 5 or less employees) it is a definite no brainer of the other sort :)