4 ms·

> but they don't give a damn about contributions Here is a concrete reason why Google open source sucks when it comes to contributions and I don't think it ca

by kccqzy 2y ago

> but they don't give a damn about contributions Here is a concrete reason why Google open source sucks when it comes to contributions and I don't think it can be improved unless Google changes things drastically: (1) an external contributor makes a nice change and a PR on GitHub; (2) the change breaks internal use cases and their tests; (3) the team is unwilling to fix the PR or port the internal test (which may be a test several layers down the dependency tree) to open source. > making it easy for you to use the projects Google internally use Blaze, a version of Bazel. It's so ridiculously easy for one team to use another team's project that even just thinking about what the rest of us needs to do to use another project is unloved dreadful work. So people don't make that effort. I do not see either of these two points changing. Sure there are individuals at Google that really care about open source community, but most don't, and so their project is forever a cathedral not a bazaar.

scrubs 2y ago
Google wants to be technically persuasive -- a player in an engineering space (ergo open source) -- without being beset with the roles and responsibilities of a 3rd party being a bonafide customer when push comes to shove.
DanielHB 2y ago
It is not only that, but often when google uses an open source project not owned by them they either try to take ownership of the project or fork it instead of trying to contribute to the original.
- jsnell 2y ago
  Which cases did you have in mind? Seems like it should be easy to find half a dozen examples since you claim it happens often.
  - Create 2y ago
    KHTML, officially discontinued in 2023. -- "Embrace, extend, and extinguish" (EEE) also known as "embrace, extend, and exterminate", is a phrase that the U.S. Department of Justice. It's also possible that President-elect Donald Trump may interfere with the DOJ's proposed remedies; he said on the campaign trail that a Google break-up may not be desirable since it could "destroy" a company that the US highly values.
    - jsnell 2y ago
      The GP's complaint was that Google "took over projects" or "forked them without trying to contribute to the original". In the case of KHTML, they never used it in the first place, so it seems like a particularly inappropriate example. I assume you actually meant Webkit? In that case, they spent half a decade and thousands of engineer-years contributing to Webkit, so it doesn't fit the original complaint about not "trying to contribute" either.
      - Create 2y ago
        November 4, 1998; 26 years ago (KHTML released) June 7, 2005; 19 years ago (WebKit sourced) https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/css/css_grouping_rule.h https://chromium.googlesource.com/chromium/src/+/HEAD/third_... * (C) 1999-2003 Lars Knoll (knoll@kde.org) * (C) 2002-2003 Dirk Mueller (mueller@kde.org) * Copyright (C) 2002, 2006, 2008, 2012 Apple Inc. All rights reserved. * Copyright (C) 2006 Samuel Weinig (sam@webkit.org) "...they never used it in the first place"
        rcxdude 2y ago
        I think the point is that KHTML was already forked into webkit by apple long before google came along (though, they have in fact also now forked webkit into blink).
        Create 2y ago
        Thank you, I rest my case. I didn't even need to bring up the DragonEgg cartel (Chandler?) going down the gcc-llvm-clang pathway used essentially for getting rid of the pesky GPL quoted above. With BSD-style, source code is no longer any of your business (not to mention chrome-chromium differences along the textbook AndroidTV tivoization).
        jsnell 2y ago
        Again, that seems to be in no way demonstrating the pattern that was claimed to be happening often. AFAIK Google did not take ownership of gcc, nor did they try to fork it without contributing to the original. They used GCC for a good couple of decades while contributing to it, but eventually switched to a different compiler. The same for clang, they neither "took it over" nor "forked it without trying to contribute".
- ghosty141 2y ago
  That's pretty common though? I mean isn't that part of the idea of open source? Forking is a pretty central part. I don't see a problem here. Why should google have to deal with the opinions of a maintainer if they can just maintain their own version. Yeah obviously it would be nice if they'd contribute their changes back to the upstream repo but from a business perspective it's often not worth it. At my company the inverse of this problem happened way more often: We find a problem but the maintainer just doesn't care. For example the backward-cpp library is a good example where the maintainer just isn't that active in the issues. Why wait for him to respond if you can just fork it and keep on moving.
rahkiin 2y ago
One could ask whether Google works ‘open source’ or more ‘source available’; the source is there but you cannot contribute, if you can build it at all
- kccqzy 2y ago
  No, "open source" doesn't imply open contribution. The standard terminology is cathedral vs bazaar.
  - interroboink 2y ago
    Just to add a different perspective: sometimes people mean Open Source[1] when they say "open source," and sometimes they don't. Personally, I take the cathedral/bazaar distinction to indicate different development cadences and philosophies, rather than whether contributions are allowed/encouraged. Various cathedral-style projects (eg: FreeBSD, Emacs) still actively take contributions and encourage involvement. There's something even further along the spectrum that's "we provide dumps of source code, but don't really want your patches." I'm not sure what the best term is for that, but "source [merely] available" sometimes has that connotation. [1] https://opensource.org/osd https://opensource.org/osd
    - kccqzy 2y ago
      The quintessential example for providing source and discouraging contributions is SQLite. Nobody would argue that it's merely source available. It is full open source. In fact "source available" usually means you can see the source code, but there are severe restrictions on the source, such as no permission to modify the source even for your own use, or no permission to create forks of the project containing the modifications, or severe restrictions on such modifications. An example is MongoDB's Server Side Public License, which is source-available but not open source.
      - steve_gh 2y ago
        I think it depends on the contribution. I sent a bug report with a minimal test case. It was welcomed and quickly fixed. It is not a source code contribution, but I think it is a contribution.

by kccqzy 2y ago

scrubs 2y ago

Google wants to be technically persuasive -- a player in an engineering space (ergo open source) -- without being beset with the roles and responsibilities of a 3rd party being a bonafide customer when push comes to shove.

DanielHB 2y ago

It is not only that, but often when google uses an open source project not owned by them they either try to take ownership of the project or fork it instead of trying to contribute to the original.

jsnell 2y ago
Which cases did you have in mind? Seems like it should be easy to find half a dozen examples since you claim it happens often.
- Create 2y ago
  KHTML, officially discontinued in 2023. -- "Embrace, extend, and extinguish" (EEE) also known as "embrace, extend, and exterminate", is a phrase that the U.S. Department of Justice. It's also possible that President-elect Donald Trump may interfere with the DOJ's proposed remedies; he said on the campaign trail that a Google break-up may not be desirable since it could "destroy" a company that the US highly values.
  - jsnell 2y ago
    The GP's complaint was that Google "took over projects" or "forked them without trying to contribute to the original". In the case of KHTML, they never used it in the first place, so it seems like a particularly inappropriate example. I assume you actually meant Webkit? In that case, they spent half a decade and thousands of engineer-years contributing to Webkit, so it doesn't fit the original complaint about not "trying to contribute" either.
    - Create 2y ago
      November 4, 1998; 26 years ago (KHTML released) June 7, 2005; 19 years ago (WebKit sourced) https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/core/css/css_grouping_rule.h https://chromium.googlesource.com/chromium/src/+/HEAD/third_... * (C) 1999-2003 Lars Knoll (knoll@kde.org) * (C) 2002-2003 Dirk Mueller (mueller@kde.org) * Copyright (C) 2002, 2006, 2008, 2012 Apple Inc. All rights reserved. * Copyright (C) 2006 Samuel Weinig (sam@webkit.org) "...they never used it in the first place"
      - rcxdude 2y ago
        I think the point is that KHTML was already forked into webkit by apple long before google came along (though, they have in fact also now forked webkit into blink).
        Create 2y ago
        Thank you, I rest my case. I didn't even need to bring up the DragonEgg cartel (Chandler?) going down the gcc-llvm-clang pathway used essentially for getting rid of the pesky GPL quoted above. With BSD-style, source code is no longer any of your business (not to mention chrome-chromium differences along the textbook AndroidTV tivoization).
        jsnell 2y ago
        Again, that seems to be in no way demonstrating the pattern that was claimed to be happening often. AFAIK Google did not take ownership of gcc, nor did they try to fork it without contributing to the original. They used GCC for a good couple of decades while contributing to it, but eventually switched to a different compiler. The same for clang, they neither "took it over" nor "forked it without trying to contribute".
ghosty141 2y ago
That's pretty common though? I mean isn't that part of the idea of open source? Forking is a pretty central part. I don't see a problem here. Why should google have to deal with the opinions of a maintainer if they can just maintain their own version. Yeah obviously it would be nice if they'd contribute their changes back to the upstream repo but from a business perspective it's often not worth it. At my company the inverse of this problem happened way more often: We find a problem but the maintainer just doesn't care. For example the backward-cpp library is a good example where the maintainer just isn't that active in the issues. Why wait for him to respond if you can just fork it and keep on moving.

rahkiin 2y ago

One could ask whether Google works ‘open source’ or more ‘source available’; the source is there but you cannot contribute, if you can build it at all

kccqzy 2y ago
No, "open source" doesn't imply open contribution. The standard terminology is cathedral vs bazaar.
- interroboink 2y ago
  Just to add a different perspective: sometimes people mean Open Source[1] when they say "open source," and sometimes they don't. Personally, I take the cathedral/bazaar distinction to indicate different development cadences and philosophies, rather than whether contributions are allowed/encouraged. Various cathedral-style projects (eg: FreeBSD, Emacs) still actively take contributions and encourage involvement. There's something even further along the spectrum that's "we provide dumps of source code, but don't really want your patches." I'm not sure what the best term is for that, but "source [merely] available" sometimes has that connotation. [1] https://opensource.org/osd https://opensource.org/osd
  - kccqzy 2y ago
    The quintessential example for providing source and discouraging contributions is SQLite. Nobody would argue that it's merely source available. It is full open source. In fact "source available" usually means you can see the source code, but there are severe restrictions on the source, such as no permission to modify the source even for your own use, or no permission to create forks of the project containing the modifications, or severe restrictions on such modifications. An example is MongoDB's Server Side Public License, which is source-available but not open source.
    - steve_gh 2y ago
      I think it depends on the contribution. I sent a bug report with a minimal test case. It was welcomed and quickly fixed. It is not a source code contribution, but I think it is a contribution.