5 ms·

We have about 100 private repos at the moment, including internal tools, branding related components, infrastructure code and pre-release stuff that we're not d

by fps 10y ago

We have about 100 private repos at the moment, including internal tools, branding related components, infrastructure code and pre-release stuff that we're not developing in the open. We may just move those to AWS code commit, gitlab or gogs and switch back to a free org.

Q6T46nT668w6i3m 10y ago
FWIW, I work for an academic non-profit and we use public repositories with an appropriate LICENSE. We like it because we don't need to manage read permissions.
VLM 10y ago
"that we're not developing in the open" 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.
- geofft 10y ago
  Non-profit organizations still have a mission that they need to protect, and they almost always have revenue they care about, though not profit. Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place. (They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.) There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
- slantyyz 10y ago
  My first job out of university was at a not-for-profit, and it is a surprisingly cut-throat sector. We had two main competitors in our space, and while the ultimate goal for everyone including our competitors was to do a common good, we were competing for a limited pool of donation dollars. Because of that, sharing any intellectual property that made us better at what we did (i.e., raise more money, hire more staff, fund more initiatives) could result in a competitor using that same IP to put us out of business. I get that in the big picture, it's not the way things should be done, but in the small picture, you're usually talking about individuals with their own agendas.
- __jal 10y ago
  There are a ton of reasons not to develop in the open, no matter what your structure. - You're experimenting - You don't want comments from the peanut gallery while things are in progress - It is not for external use, specific to an institution or project, or otherwise nobody else will care - It deals with something sensitive - You've made an agreement with someone else that requires it - etc. etc. etc. People seem to have weird notions about nonprofits. Your tax structure doesn't change the fact that you operate in a world of other human beings.
  - fps 10y ago
    mostly these reasons. We also want to make sure that code we open source is properly documented, has appropriate functional tests, and is useful outside of our organization. Our typical workflow is to build a POC, then an MVP, then build out documentation and unit tests.
woah 10y ago
What kind of bad things will happen if people are able to see what you are doing?
sytse 10y ago
You're very welcome to switch to GitLab.com, we are free forever https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-free-forever https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-... and it can import directly from GitHub.
- puddintane 10y ago
  GitLab CE (Community Edition is Free) and is truly great we use it in our own internal software development process. However for a bigger enterprise they require more functionality here is a comparison of the differences between the Community and Enterprise Editions. https://about.gitlab.com/features/#compare https://about.gitlab.com/features/#compare Several pricing options for EE but essentially the base cost is $39 /year per user. https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/
  - gpm 10y ago
    gitlab.com runs EE though doesn't it? You only need to pay if you want self hosted EE.
    - puddintane 10y ago
      I've only ever seen the trial but I could be wrong!
    - connorshea 10y ago
      It does, yes :)
      - puddintane 10y ago
        Great to know, thank you! However our requirements were offsite and must be why I never knew about the free EE hosted on GitLab!
  - X-Istence 10y ago
    You are replying to the CEO of Gitlab... :P
BHSPitMonkey 10y ago
Your first comment stated the problem was your large number of non-employee contributors. You said in another comment that non-employees don't contribute to your private repos. 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).

by fps 10y ago

Q6T46nT668w6i3m 10y ago

FWIW, I work for an academic non-profit and we use public repositories with an appropriate LICENSE. We like it because we don't need to manage read permissions.

VLM 10y ago

"that we're not developing in the open" 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.

geofft 10y ago
Non-profit organizations still have a mission that they need to protect, and they almost always have revenue they care about, though not profit. Private repos are a good way to review code for things like plaintext passwords and service keys before it's in production. If a developer commits something with a key, and code review goes "Oh, you shouldn't have put that there," and it was public, now you have to rekey. Private repos allow that code review step to take place. (They're also pretty useful for legacy code where eliminating all the private keys is difficult and not an immediate priority, and for the rare but existent cases where including private keys in source is the right engineering tradeoff for new development.) There's also no way to disable pull requests and other outside comments on your code, other than making a private repo. Having it private is a simple way to avoid inviting the public to have opinions all over your repo.
slantyyz 10y ago
My first job out of university was at a not-for-profit, and it is a surprisingly cut-throat sector. We had two main competitors in our space, and while the ultimate goal for everyone including our competitors was to do a common good, we were competing for a limited pool of donation dollars. Because of that, sharing any intellectual property that made us better at what we did (i.e., raise more money, hire more staff, fund more initiatives) could result in a competitor using that same IP to put us out of business. I get that in the big picture, it's not the way things should be done, but in the small picture, you're usually talking about individuals with their own agendas.
__jal 10y ago
There are a ton of reasons not to develop in the open, no matter what your structure. - You're experimenting - You don't want comments from the peanut gallery while things are in progress - It is not for external use, specific to an institution or project, or otherwise nobody else will care - It deals with something sensitive - You've made an agreement with someone else that requires it - etc. etc. etc. People seem to have weird notions about nonprofits. Your tax structure doesn't change the fact that you operate in a world of other human beings.
- fps 10y ago
  mostly these reasons. We also want to make sure that code we open source is properly documented, has appropriate functional tests, and is useful outside of our organization. Our typical workflow is to build a POC, then an MVP, then build out documentation and unit tests.

woah 10y ago

What kind of bad things will happen if people are able to see what you are doing?

sytse 10y ago

You're very welcome to switch to GitLab.com, we are free forever https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-free-forever https://about.gitlab.com/gitlab-com/#why-gitlab-com-will-be-... and it can import directly from GitHub.

puddintane 10y ago
GitLab CE (Community Edition is Free) and is truly great we use it in our own internal software development process. However for a bigger enterprise they require more functionality here is a comparison of the differences between the Community and Enterprise Editions. https://about.gitlab.com/features/#compare https://about.gitlab.com/features/#compare Several pricing options for EE but essentially the base cost is $39 /year per user. https://about.gitlab.com/pricing/ https://about.gitlab.com/pricing/
- gpm 10y ago
  gitlab.com runs EE though doesn't it? You only need to pay if you want self hosted EE.
  - puddintane 10y ago
    I've only ever seen the trial but I could be wrong!
  - connorshea 10y ago
    It does, yes :)
    - puddintane 10y ago
      Great to know, thank you! However our requirements were offsite and must be why I never knew about the free EE hosted on GitLab!
- X-Istence 10y ago
  You are replying to the CEO of Gitlab... :P

BHSPitMonkey 10y ago

Your first comment stated the problem was your large number of non-employee contributors. You said in another comment that non-employees don't contribute to your private repos. 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).