Live data from Hacker News

Finding Critical Open Source Projects

opensource.googleblog.com

101–102 of 102 posts

Re: Finding Critical Open Source Projects

#101
post #2

Very interesting and I hope this leads to actual recompense/compensation for people "thanklessly maintaining" OSS. Not sure how it possibly fits into Google's newfound profit-at-all-costs motive, but the gesture is an important first step towards some semblance of justice.

Can you elaborate more on the claimed "profit-at-all-costs" statement? It's been established that the purpose of most corporations are for profit, but iirc most large enterprises have a rather robust ethics framework when working with the OSS community.

I wish I had reasonable evidence to point to, but I'm not really an insider. Mainly, I think of the numerous applications Google invested lots of engineer time into to create an experience, say Hangouts, only to realize that it hampered sales in another corner of Google, say cell plans, and so one project must be discarded for profits in the other. The functionality is often difficult to replace for the end-user, and weakens the overall allure of the Google network/ecosystem of applications in favor of a bottom-line.

Re: Finding Critical Open Source Projects

#102
post #97
post #56

Earlier quoted context omitted.

One cool feature of functional package managers such as Nix and Guix is that the dependency graphs are entirely transparent and can be inspected programmatically. I wrote a script that lists the number of dependents for each package in Guix by traversing the package graphs: https://gist.github.com/mbakke/f354272666fbef09c5229f7b85377... Running it takes about 16 seconds on my laptop, and piping to 'grep -v bootstrap…

analysing a source-only-based distro (one where the compiler is required as a dependency) should make the importance of the compiler(s) clearer. source-only distros include macports, gentoo, and so on.

Guix and Nix _are_ source-based distros. They just happen to have a facility for transparently downloading "binary substitutes" for local builds.

The graphs I'm traversing are the build-time dependency graph of all packages. I could also traverse run-time dependency graphs, but then I'd need to actually build all the things, because those are not known up-front unlike Gentoo and Macports.

The reason the toolchain is missing is because it is an "implicit input" as opposed to a "normal" input, so it's invisible/transparent to the query I'm making.

Post reply on HN