Earlier quoted context omitted.
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.
Introducing unlimited private repositories
381–390 of 662 posts
Re: Introducing unlimited private repositories
#382Earlier quoted context omitted.
And for us it's negative, our monthly bill has just increased by hundreds of dollars. In theory, our respective organisations could be in competition, and GitHub has just increased our monthly bill to subsidise your organisation, instead of shouldering the financial burden themselves.
> GitHub has just increased our monthly bill to subsidise your organisation, instead of shouldering the financial burden themselves. This is a really weird argument. They are a company supplying a service, why should they ever have to shoulder the bill? I'd argue that if things stayed the same, this small company would subsidize you: if you have 100 accounts using 1 repo it's more likely you're using more resources t…
Edit: My parent post is being down voted and that's fine, my point was not made in anger, it was an observation that smaller companies are having their monthly costs decreased, and the larger companies are seeing an increase, for organisations created after today that's a fair premise, but for those organisations that have been using GitHub for years and have now seen their monthly costs increase, it's a slap in the face.
Re: Introducing unlimited private repositories
#383Earlier quoted context omitted.
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…
If you no longer want/need the social aspects of GitHub, you can just move to GitLab. Much more affordable and you can self host it yourself. We have an on premise GitLab installation. Besides the rare upgrade, it's pretty hands off. And it's costing us $0 in licensing fees for over 60 users ;-)
We install every incremental update, which GitLab publishes very frequently -- weekly or several times a month. They are always seamless. The GitLab team is working so hard.
https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELO...
Re: Introducing unlimited private repositories
#384I find it quite hard to comprehend why people use Github for private repositories. There are many free alternatives. BitBucket seems to be the famous one, but Gitlab has grown into an amazing product with 3 different offerings; On premise community edition, on premise enterprise and hosted (like Github). We have used the on premise community edition for about 3 years now. I first installed it when you had to run abou…
If every organization went to free alternatives, not only would those free alternatives need a source of revenue to support the new business, I think you'd find they too will change their pricing structure to better fit the people that use their product. One thing I also have to mention is a majority of for profit organizations have no problem paying for services they use. HN is a special snowflake on the internet, i…
Re: Introducing unlimited private repositories
#3851. 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…
Re: Introducing unlimited private repositories
#386Earlier quoted context omitted.
We are reaching out to customers that are in unique situations such as the one you're mentioning here. If you have questions about how the pricing changes affect you, please don’t hesitate to contact support@github.com.
If you need to give Epic Games special treatment just because they have a huge amount of outside collaborators, then your pricing model is broken. It would be more fair to charge $9/mo per organization member + $1/mo per active outside collaborator (somewhat similar to AWS CodeCommit) than to charge for every single active and inactive member and collaborator equally. Maybe throw in a 50% bulk discount for active out…
This is an unfair thing to say. Exceptions to otherwise simple rules does not at all mean that the simple rules are "broken".
It is also an unfair thing to say since he clearly says that not only is Epic Games getting this treatment, so is everyone in a similar situation. Furthermore, it has always been possible to negotiate special pricing for special cases. Just send them a message. That is how sales works at almost every company.
Re: Introducing unlimited private repositories
#387Earlier quoted context omitted.
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
Re: Introducing unlimited private repositories
#388Earlier quoted context omitted.
If you are non profit and open source do you really need private repos?
In a non-profit that I collaborate with [1] we use private repos to keep the server setup and some tickets that contain sensitive information (user data). All other code is open source. Obviously we don't want to keep api keys etc. in the public repos. [1] https://github.com/sozialhelden/wheelmap
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
Re: Introducing unlimited private repositories
#389Earlier quoted context omitted.
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
care to explain why? I need to keep my API keys somewhere so I can roll them out to the machine. Keeping them in git is as good as any storage - what would you propose instead? A shared dropbox account?
Re: Introducing unlimited private repositories
#390Earlier quoted context omitted.
You shouldn't be keeping api keys or other sensitive information in git at all . And please note -- if you do remove it from git, it will be available in your git history so that needs to be taken care of as well (should the repo ever become public -- a common "exploit").
Git is just a format for storing data with a record of how that data changed. Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. It's true that if your btrfs disk image becomes public, the data is recoverable, and it's hard to reliably scrub deleted files from btrfs, but that doesn't mean it's the wrong tool for a filesystem (or a repo) that stays entirely internal. Saying…