Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Criteria #22

Closed
staltz opened this issue Jun 26, 2017 · 14 comments
Closed

Criteria #22

staltz opened this issue Jun 26, 2017 · 14 comments

Comments

@staltz
Copy link
Collaborator

staltz commented Jun 26, 2017

@mxstbr @piamancini @xdamman @kof What should be the criteria to include an entry?

  • Company or individuals?
  • What kind of sponsorship? Money, time, SaaS "coupons"?
  • What projects? Can Google be considered one just because it open sourced Chrome?

I'm not looking forward to being the arbiter of what companies are good enough (gladly the repo is now under a github org with others as well), I was just the one who kickstarted this thing by making a dumb initial commit, but there should be a way the list can be both useful and maintained fairly.

Too wide criteria and you end up including all companies under the sun. Too narrow criteria and it's a club. I want to hear feedback what should be the criteria, but currently given the initial Twitter thread we had, I would say the point is to identify companies that pay back to third-party open source projects, so I'd recommend the criteria "open source software not produced through company time linked to the company's business model", which rules out cases like GitLab Inc, etc, unfortunately.

@mxstbr
Copy link

mxstbr commented Jun 26, 2017

"open source software not produced through company time linked to the company's business model"

Not produced through company time? I thought that's the whole point, finding companies going "Hey, we'll give you half a day per week to work on any OSS you want" and I'd even be fine with "Hey, we'll give you half a day per week to work on any OSS that our company uses". Imagine if a company uses Cycle and they let their employees contribute back to it, I feel like those should be included even though that is produced on company time and is linked to the company's business model.

I agree that companies like GitLab or Sentry that just are open source shouldn't count though, so what about

"Companies allowing employees to support third-party open source projects"

Where "support" can also be a monetary thing like "we'll give you $xxx/month to support a project of your choice, you can either use it yourself or pay them if you don't have the time/willingness to contribute yourself" and "third-party" just means "not made by the company". (maybe there's a better word for "third-party" that also includes the persons' open source projects? If somebody hires @staltz and let's him work on Cycle that should count eventhough that's not necessarily "third-party")

@kof
Copy link
Contributor

kof commented Jun 26, 2017

Its an interesting question, because I think the core idea is to list companies which help to reduce the "debt" created by using OSS without giving something in return.

Now companies which open source own projects do invest into open source by doing it, but yet if they don't invest anything into other OS projects, they don't help to reduce the "debt" but rather increase it.

@kof
Copy link
Contributor

kof commented Jun 26, 2017

Second interesting question is how to deal with companies like google. I think we may want to be more specific there and naming a specific team or department or whatever we can identify.

@kof
Copy link
Contributor

kof commented Jun 26, 2017

What kind of sponsorship? Money, time, SaaS "coupons"?

Dunno what coupons are and how they can help, to me its only money and time.

@kof
Copy link
Contributor

kof commented Jun 26, 2017

Btw. companies open sourcing their projects often are either NOT reducing the debt, or they are even increasing it. Here are some examples that happen:

  1. Open sourced something that is not really useful to others. For e.g. some internal tool, highly coupled with something else nobody has.
  2. Bad license which doesn't allow most of us use it.
  3. Open sourced some code but not the knowledge. For e.g. no documentation or too bad documentation.
  4. No open dev process. Project is developed in private conversations, nobody knows from the outside where it is heading to nor what to expect.
  5. Building every module by themselves, not using work of others.
  6. Not handling user requests in form of issues or pull requests

@piamancini
Copy link

quoting @andrew here from a side chat on this: “companies that pay people to contribute to projects that they don’t control"

@mxstbr
Copy link

mxstbr commented Jun 26, 2017

I like that wording! Let's combine that with what I stated above into

"Companies that let employees support open source projects that they don't control"

To avoid edge cases and make the criteria clear here's some definitions that should apply strictly:

  • "support": Can mean both in terms of time (let people contribute) as well as in terms of money. (let people sponsor projects)
  • "open source projects": Any project under one of the licenses that comply with the open source definition as listed (and defined) on https://opensource.org/licenses
  • "that they don't control": Self explanatory, but a notable edge case that'll come up is companies that hire the creator of a project. (like somebody hiring @staltz to maintain cycle.js) I'd say those should be included, but I'm happy to reconsider if you don't agree.

@tbarn
Copy link

tbarn commented Jun 26, 2017

I'm curious about the in-kind sponsorships too. When you give discounts or coupons (a lot of time it is basically free usage) of software, it is saving the project money if they wanted to use those pieces of software otherwise.

I've had conversations in the past with some open source maintainers that they see this as a form of support. The usefulness of it can really depend on the project and what is being given in-kind.

@staltz
Copy link
Collaborator Author

staltz commented Jun 26, 2017

Yeah @mxstbr understood me and improved the wording there. I think I can help define more precisely what "third-party" is: when the copyright holder in the license is not the company itself. E.g. this is not third-party https://github.com/facebook/react/blob/master/LICENSE#L5

but a notable edge case that'll come up is companies that hire the creator of a project.

This is already the case of No Red Ink and Evan Czaplicki, but it's convenient that the copyright holder is Evan and not No Red Ink: https://github.com/elm-lang/elm-compiler/blob/master/LICENSE#L1

@abitrolly
Copy link

Also, it is a sufficient criteria for a global corporations to spend 0.00001% of its income once in 10 years to be considered a supporter of OSS?

@staltz
Copy link
Collaborator Author

staltz commented Jun 26, 2017

That's something I thought about as well, but obviously not all companies will uniformly contribute to open source in proportion to their revenues. In the ideal case this list would include (1) contribution size per year, (2) revenue per year, for each company.

For now, I would not include or delay inclusion of entries that don't seem to do significant open source sponsoring.

@kof
Copy link
Contributor

kof commented Jun 26, 2017

Obviously not in every product software has any direct relationship with revenue. I wouldn't even start going this direction. It should be more about compensations for invested time.

@abitrolly
Copy link

@kof why did you link product software here? The income concept is irrelevant to whatever company is building its product on top of OSS or even selling it as is. It solely a metrics whatever a company of 1800 ppl. can be considered an OSS supporter if it gave a one time $500 donation to PSF or similar entity and be on the same list as 5 people company that gives 1% of its income to open source projects it uses.

@staltz
Copy link
Collaborator Author

staltz commented Jun 26, 2017

There are now some criteria in the README.md. If we need to address some new topic around this, we can open another issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants