Live data from Hacker News

Introducing unlimited private repositories

github.com

561–570 of 662 posts

Re: Introducing unlimited private repositories

#561

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…

Per user pricing makes a lot more sense than per repo pricing. This way larger organizations pay more money than smaller ones regardless of how they structure their code. This is a good deal for small organizations that like to have many small repositories (for internal libraries, utilities, micro services, modules, etc). Sure, it screws up a few models that rely on external collaborators to get access to private rep…

Price per idle/obsolete etc repo - $1.5-$2.5/month and goes down with number of repos. Price per idle/noncontributing user - $9/month and it stays constant.

In any case, for my org it would mean ~5x cost increase. So yes, nice spin.

Re: Introducing unlimited private repositories

#562
post #513

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'd appreciate if their PR department didn't expect us to swallow this as a positive change. it really depends on your perspective. i significantly prefer per-user over per-repo. i can see how per-repo might benefit others, however.

Why not have both options continue to be available?

Re: Introducing unlimited private repositories

#563
post #492
post #439

Earlier quoted context omitted.

I've used Bitbucket in the past. They charge per-user[1], and their pricing is significantly better free for 5 users and then once you eclipse 5 users it's $1/user up to 100 users and then $200 for unlimited users. [1] - https://bitbucket.org/product/pricing

This. I use bitbucket too and I can't understand why people are still paying github when bitbucket does exactly the same and is free.

These services are not the same, not since I last checked. Someone forks your repo, makes a change and then submits a PR. I can't pull their changes down until they give me read access to their forked repo.

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.

Re: Introducing unlimited private repositories

#564
post #530

Earlier quoted context omitted.

> We have lots of people who aren't employees, but have signed a contributor agreement with our organization and contribute changes to our software. 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...

the software is AGPLv3'd, and run by hundreds of educational organizations around the world. Those organizations typically contribute changes back via Github. Non-employees don't contribute to our private repositories. We gain quite a bit from maintaining a large open source community, but it's not "free labor."

From the announcement:

"These users do not fill a seat:

Outside collaborators with access to only public repositories"

Re: Introducing unlimited private repositories

#567

Earlier quoted context omitted.

People use github over bitbucket if they like the features that github provides, the diffs, issues etc. Not sure which features are unique to github alone, but each provider (including gitlab) has their own flavor. Many are just used to github flavor.

I use bitbucket at work, and it has many of the same features as github. The UI is a bit clunkier, and it does lack some of the flashy features such as automatically squashing commits when merging a pull request. However it does work fine, and it is well integrated with atlassian's other offerings which we also use. Mainly JIRA and hipchat, though bitbucket also has a per-repository issue tracker.

An aside, but I hate that squash feature more and more each day at my job.

Re: Introducing unlimited private repositories

#568
post #530

Earlier quoted context omitted.

> We have lots of people who aren't employees, but have signed a contributor agreement with our organization and contribute changes to our software. 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...

the software is AGPLv3'd, and run by hundreds of educational organizations around the world. Those organizations typically contribute changes back via Github. Non-employees don't contribute to our private repositories. We gain quite a bit from maintaining a large open source community, but it's not "free labor."

I apologize- I thought volunteers were contributing to your private repos. If I understand correctly, your issue is that you have (say) 10 employees accessing private repos and 100 contributors to public/Free ones, but you're to be charged for all users you add to your org? I can see how this would be frustrating.

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. :)

Re: Introducing unlimited private repositories

#569
post #500

Earlier quoted context omitted.

> Best practice is to avoid storing secrets in plaintext How do you store them, then? If they're encrypted with a password, how do you store that secret? I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means…

TPM. It's just one role, but multiple users.

Do you have any tools you recommend for that? I love TPMs, but this seems wildly impractical for a small project with developers who aren't excited about becoming TPM experts.

Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)

Re: Introducing unlimited private repositories

#570

Earlier quoted context omitted.

Which I already was. Now I'm paying less, and getting more.

But since they now are limiting the number of contributors to your private repos, you might as well use BitBucket for free.

I do, some? When I bumped up against the repo limit in GitHub, and didn't want to increase my account size. But it always felt like a cheap knock-off, so I don't spend much time there; generally I'd clear out an older repo, or just bump up my account.
Post reply on HN