3 ms·

Just a couple of example scenarios: - Someone sells you BPF observability that's buggy and dissapointing, and you avoid BPF in the future. So in that case it's

Just a couple of example scenarios: - Someone sells you BPF observability that's buggy and dissapointing, and you avoid BPF in the future. So in that case it's hurt the BPF community. - Funding goes to a project that gives nothing back, instead of funding a project that does. Again, it hurts the community as funding isn't infinite.

kortilla 5y ago
> Someone sells you BPF observability that's buggy and dissapointing, and you avoid BPF in the future. So in that case it's hurt the BPF community. Ok, so someone sells me closed source tooling that uses BPF and it’s buggy and disappointing, so I avoid BPF in the future. This association problem exists regardless of closed source vs a fork vs an old release. > Funding goes to a project that gives nothing back, instead of funding a project that does. Again, it hurts the community as funding isn't infinite. This only hurts if it’s a closed/hidden fork. This also presumes that the fork isn’t just stripping out tons of upstream features (I’ve had to do this for clients because “security”). My view is that forks of open source (GPL in particular) should be encouraged and done in public. Iterating on central projects only is just so slow and stifling. Maybe your projects have very little churn so lots of people experimenting in parallel doesn’t make sense, but this has been my experience with larger infrastructure projects. Let a thousand flowers bloom.