A small comparison: Team | Cost Before | Cost Now 1 repo, 5 users | $25 | $25 1 repo, 10 users | $25 | $70 11 repos, 5 users | $50 | $25 11 repos, 10 users | $50 | $70 5 repos, 50 users | $25 | $430 50 repos, 5 users | $100 | $25 50 repos, 50 users | $100 | $430 I'm not sure how common are organizations with few users and large number of repose - I guess software houses that keep old projects (for maintenance and fut…
We have a few users and a large number of repos - small team of developers supporting research projects in a university department.
1. Take a gazillion dollars in funding on an over-hyped valuation, 2. Go through significant organizational changes that end up with the departure of a co-founder (and more suits in the building). 3. Notice that a significant segment of your growth (VC-funded startups) are running out of money. 4. Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool un…
I actually love it and I'm thankful for Github's consistently great service - looking forward to all the bitbucket/gitlab customer project migrations over the coming months.
I'd fire the PR department if they didn't give this a positive spin.
That doesn't mean that customers can't be annoyed being sold for stupid. The release announcement forgets to mention that collaborators are now costly - either a stupid oversight or part of the positive spin. A good marketing department should display things in a positive fashion, but they should also strive to be honest, so they're not loosing credibility.
I see it is honest and very positive and supportive
Compared to products like Salesforce, GitHub seems cheap to me. What to you is a fair price and why?
> GitHub seems cheap to me At $9/user/mo, github is 900% more expensive than the $1/user/mo direct competitor BitBucket. BitBucket uses brackets rather than pure scaling, but their most expensive option - 101 users require the $200 unlimited accounts plan - is still only $2/user.
Maybe it's time to charge more for those closed source projects, just saying..
Even for software houses, it's VERY problematic as we add customers to projects as external collaborators and we're going to get billed for that forever, even if most customers have very light usage, and even for non active projects. I was thrilled by this news but it's going to be completely unaffordable for us. We have 29 users and 51 external collaborators. We have recently upgraded to the Platinum plan ($2460/yr)…
I keep my eye on Microsoft's Visual Studio Team Services. It has a bit of a clunky name and aimed more at enterprises but I think at some point they will position it as a competitor to GitHub. It's free for the first five developers, and no charge for "stakeholder" user accounts. https://www.visualstudio.com/pricing/visual-studio-team-serv... So 29 users would be $182/m (check my maths) and you'd pay nothing for the…
Company I work at uses VSTS and we're happy with it. It's actually a much larger product than just code hosting, as it also includes loads of other things like Agile Planning tools, Build system (which is now much simpler than the crazy old TFS XAML based TeamBuild. Although you only get an allocation of build "minutes" every month) and Release Management (OctopusDeploy style system). You can do cool things around PRs, like enforcing that certain users, or groups of users must approve to be mergable, or that a certain build off that branch must succeed to be mergeable. All this stuff is possibe obviously in GitHub, it's just a bit more integrated. Worth checking out
A small comparison: Team | Cost Before | Cost Now 1 repo, 5 users | $25 | $25 1 repo, 10 users | $25 | $70 11 repos, 5 users | $50 | $25 11 repos, 10 users | $50 | $70 5 repos, 50 users | $25 | $430 50 repos, 5 users | $100 | $25 50 repos, 50 users | $100 | $430 I'm not sure how common are organizations with few users and large number of repose - I guess software houses that keep old projects (for maintenance and fut…
At my workplace we have 1/5 ratio of users to repositories on our git server. We tend to create separate repositories for modules, applications and even prototypes. In any case if we were to use Github their new pay-per-user model would make more sense for us than the pay-per-repository model.
That doesn't mean that customers can't be annoyed being sold for stupid. The release announcement forgets to mention that collaborators are now costly - either a stupid oversight or part of the positive spin. A good marketing department should display things in a positive fashion, but they should also strive to be honest, so they're not loosing credibility.
"loosing credibility" is subjective in this case. Some orgs/people will be better off, some won't. I recall GitHub doing some extensive research on what their customer based wanted. This is most likely the outcome of that research. If I were to migration our org. over we would be worse off. Even with that I don't think this move is disingenuous. Poorly thought through perhaps?
> Even with that I don't think this move is disingenuous.
I never said that I consider the move disingenuous. Almost no change will unilaterally benefit everybody. I dislike the communication that reads as if the change is unilaterally beneficial - where it clearly is not.
1. Take a gazillion dollars in funding on an over-hyped valuation, 2. Go through significant organizational changes that end up with the departure of a co-founder (and more suits in the building). 3. Notice that a significant segment of your growth (VC-funded startups) are running out of money. 4. Switch to a user-based pricing to generate more revenue for investors, but spin it as a freebie "Hey! Look at the cool un…
For us as a small team it's a very positive change. Our monthly bill just went from $100 to $25.
That makes a lot more sense in term of pricing and if that had existed earlier, I'd probably not have bothered hosting my own gitlab repository. I like to have a lot of little repos even keeping some of my private experiments and so the limit of repositories never really made sense to me.
It might make sense however to not count collaborators with read-only access.
Of course, now that I have gitlab, there's very little reason for me to come back.