I use Bitbucket for a variety of small, personal projects. And when I teach Git courses, I use Bitbucket to illustrate (and practice) pull, push, and pull requests (among other things). Sometimes people wonder why I'm not using GitHub, which has made itself synonymous with Git for many people, but after a short explanation, they understand.
However: GitHub has a huge network effect. Most developers with any sort of open-source connection have a GitHub account; many fewer have Bitbucket accounts. This isn't the end of the world, but it does mean that GitHub has a leg up on the competition as far as name recognition is concerned.
Plus, there are lots of tools that talk to the GitHub API.
So, while I personally endorse using BitBucket, I can understand why many would stick with GitHub. It'll be interesting to see what this price change does.
Having said that, I used to pay for Github's personal plan and found the cap on private repos (5 when I subscribed) to be a little too limiting. I ended up canceling the subscription and using a Bitbucket free account for private repos and Github for public repos.
After using Bitbucket for a while, I think if I had to upgrade to a paid service, I'd just stick to Bitbucket.
GitHub is actually painfully slow too; just not as slow.
That's the main reason I pay GitHub and use them for those projects where I need something more than just a git server for collaboration.
I found a lot of these little annoyances to be a big reason to switch to github. Not to mention their UI pales in comparison to github, which I think says a lot.
So you have volunteers, working on your proprietary, private software for free. The labor is free & now you're complaining that you'll have to pay a per-free-laborer fee for the infrastructure to manage all these free-laborers? I hope I'm missing something here...
Or say you have 80 very-part-time contributors who together match the output of 1 full-time employee, github is going to charge you as much as they would for 80 full-time employees.
Any pricing structure is going to have some people who get a great deal and other people who get screwed, but it sucks when you've selected a platform, invested in getting set up on it, and then have the pricing rug pulled out from under you.
I see two possible solutions that don't force you to switch vendors:
1. Have non-employees fork & submit pull requests. 2. Split your private stuff off to a different org & formally separate free stuff from proprietary, make the free stuff community managed.
If these are problems, I'd maintain that this is a "have your cake and eat it to" problem, on the one hand keeping ownership & control of the project and reaping the attendant benefit to the edx brand, and on the other hand getting people to hack on your stuff for free. But in any event this is a broader existential issue that exists across the OSS world right now (see express.js), so I'm probably reading too much into your case. :)
"These users do not fill a seat:
Outside collaborators with access to only public repositories"
I don't see the problem here. Your employees will have access to your private repos, and the volunteers will not (thus you won't be paying for their seats).
Honest question... why?
I totally understand the mindset of "gotta go all secret squirrel to protect our profits" but if your org isn't in it for the profits there's not much to protect?
I have seen examples of people performing very naughty acts like private repos to hold plain text passwords, plain text cloud service keys, plain text corporate credit card numbers for expense payments, etc.
Wait, what?
I've recently also have to do with this problems while doing server setup with a private repo. I'm using Ansible and Ansible Vault to encrypt sensitive data and the encryption key itself is only accessible (a password safe) to certain members of our team http://docs.ansible.com/ansible/playbooks_vault.html
"Being a nonprofit" doesn't mean "developing open source software".
Especially as you note AWS costs are much more - I'd have thought it would be much more economical to consolidate into AWS and run a VC server there.. but I'm not trying to tell you what's good for you, I'm just a guy with no experience of responsibility for things at that scale who's curious ;)
