7 ms·

SQLite, Vim/Emacs, Linux, everything in GNU coreutils. All of the Apache projects (some to more/less an extant than others). Most programming language impleme

by gen220 6y ago

SQLite, Vim/Emacs, Linux, everything in GNU coreutils. All of the Apache projects (some to more/less an extant than others). Most programming language implementations (e.g. CPython). Memcached. WireGuard. SQLAlchemy. Web Frameworks like Flask, Django, Rails, on and on. There are many open source technologies that do not seek to capture the value they create with licensing hijinks. I don’t think it’s an accident, that the ones that persist across generations are generally not structured as VC-backed firms, who care a great deal more about “value capture” than the average programmer capable of building such foundational systems. Usually “value capture” is correlated with “consumer harm”, and so they’re replaced over time. From your example, K8s will definitely outlive Google. Hard to say about Android.

Dylan16807 6y ago
> From your example, K8s will definitely outlive Google. Hard to say about Android. What leads you to say that? I wouldn't be surprised if kubernetes is dead in 20 years. I would be very surprised if google is dead in 20 years.
- BoysenberryPi 6y ago
  Frankly I'd be surprised if Kubernetes wasn't dead in 20 years.
  - ethbr0 6y ago
    Imho, K8s eventually evolves into an OS for running K8s, then gets productized on {non-x86-64}
    - edoceo 6y ago
      not looking forward to the k8s-arm-soc enabled bootloader (tightly integrated to systemd of course) to run k8s-os to run k8s-system to run docker.
- gen220 6y ago
  It’s just my opinion and I’ll be happy to be wrong (because it means something better will have supplanted it). But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s. K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel. It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course. I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.
valyala 6y ago
I fully support this statement. I'm core developer of open-source monitoring solution - VictoriaMetrics [1]. It is licensed under Apache 2 and we have no plans to change the license, since it may complicate user experience. VictoriaMetrics makes "value capture" by more future-proof means: * By providing easy-to-setup-and-operate solution * By focusing on the performance and minimal resource usage * By providing good integration with other monitoring solutions [1] https://github.com/VictoriaMetrics/VictoriaMetrics https://github.com/VictoriaMetrics/VictoriaMetrics
nine_k 6y ago
I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed) don't do well! They do, and I'm happy about it. Some have commercial entities around them, but most don't. What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak. In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.
- gen220 6y ago
  Ah yeah! We totally agree! I was finding it hard to respond to your comment initially because I didn’t know which point you were trying to make, mentioning Android and K8s. I totally agree that the “we are now AGPL” route is preferable. FWIW MongoDB was already AGPL, but that wasn’t enough for them I guess, they wanted more money. Old HN thread on the topic: https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229452
  - gqewogpdqa 6y ago
    Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?
    - gen220 6y ago
      Sorry you’re right, I was being petty. I’ll explain my perspective in hope that we can learn something from this, but being flippant like that wasn’t justifiable. That’s a lesson in itself! :) From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise. I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great. More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world. From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain. But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.

by gen220 6y ago

Dylan16807 6y ago

> From your example, K8s will definitely outlive Google. Hard to say about Android. What leads you to say that? I wouldn't be surprised if kubernetes is dead in 20 years. I would be very surprised if google is dead in 20 years.

BoysenberryPi 6y ago
Frankly I'd be surprised if Kubernetes wasn't dead in 20 years.
- ethbr0 6y ago
  Imho, K8s eventually evolves into an OS for running K8s, then gets productized on {non-x86-64}
  - edoceo 6y ago
    not looking forward to the k8s-arm-soc enabled bootloader (tightly integrated to systemd of course) to run k8s-os to run k8s-system to run docker.
gen220 6y ago
It’s just my opinion and I’ll be happy to be wrong (because it means something better will have supplanted it). But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s. K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel. It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course. I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.

valyala 6y ago

I fully support this statement. I'm core developer of open-source monitoring solution - VictoriaMetrics [1]. It is licensed under Apache 2 and we have no plans to change the license, since it may complicate user experience. VictoriaMetrics makes "value capture" by more future-proof means: * By providing easy-to-setup-and-operate solution * By focusing on the performance and minimal resource usage * By providing good integration with other monitoring solutions [1] https://github.com/VictoriaMetrics/VictoriaMetrics https://github.com/VictoriaMetrics/VictoriaMetrics

nine_k 6y ago

I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed) don't do well! They do, and I'm happy about it. Some have commercial entities around them, but most don't. What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak. In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.

gen220 6y ago
Ah yeah! We totally agree! I was finding it hard to respond to your comment initially because I didn’t know which point you were trying to make, mentioning Android and K8s. I totally agree that the “we are now AGPL” route is preferable. FWIW MongoDB was already AGPL, but that wasn’t enough for them I guess, they wanted more money. Old HN thread on the topic: https://news.ycombinator.com/item?id=18229452 https://news.ycombinator.com/item?id=18229452
- gqewogpdqa 6y ago
  Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?
  - gen220 6y ago
    Sorry you’re right, I was being petty. I’ll explain my perspective in hope that we can learn something from this, but being flippant like that wasn’t justifiable. That’s a lesson in itself! :) From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise. I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great. More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world. From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain. But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.