3 ms·

> That’s how you get contributions that are huge hacks and require more work to review and iterate on than is worth it to the community. And yet the author her

> That’s how you get contributions that are huge hacks and require more work to review and iterate on than is worth it to the community. And yet the author here is saying please work together. Presumably he or the community is okay with picking apart those huge hacks. I'm not sure why you should care what that community is willing to accept, unless you're part of it. > If some company forks for an observability product and doesn’t contribute back, they clearly don’t want to. Don’t try to force them. Who's forcing anyone? Did you not notice the "please" he starts that statement with? > Demanding people contribute to your project instead of forking just sounds like demands to pay homage more than anything. That's just a straw man, nobody demanded anything, and I'm not sure why you'd even try to insinuate he was when he literally says please. If I had to paraphrase the part of the post you're critiquing, I would do so as "If you're using these tools, don't feel like you have keep any stuff you do separate. We'd like to build something better for everyone, so feel free to contribute to the project rather than keeping it separate and we can all build on each other's work." That's pretty standard open source ideals IMO.

brendangregg 5y ago
I appreciate the discussion as I want to do a follow on post about this in more detail. It doesn't do the BPF community any good to have people running old broken versions of my tools (just as back in 2005, Sun was selling DTrace by distributing my half-finished socketsnoop.d). Now, some people are going to port anyway regardless of what's good for BPF. But if I can reach developers who may be on the fence about it, I can explain the pros of just building upon the existing tools. To start with, you get updates for free by kernel engineers at Facebook, Netflix, etc. Also, by pushing fixes back you'll find people will try to help you in return for when you need it (some startups, like Cilium, have done so much for BPF that I'd happily help them with anything they need (provided there isn't a clash with my current employment)).
kortilla 5y ago
> If I had to paraphrase the part of the post you're critiquing, I would do so as "If you're using these tools, don't feel like you have keep any stuff you do separate. We'd like to build something better for everyone, so feel free to contribute to the project rather than keeping it separate and we can all build on each other's work." That's pretty standard open source ideals IMO. Sure, that’s just a completely different writing of what’s actually there. The original post is an instruction not to do something. Your interpretation is a much more open “pull requests accepted”. His reply clarifies that he doesn’t want broken shit out there so your reading is incorrect. He does want to discourage forks because they are subtle to get correct and doesn’t want shit out their sullying bpf’s reputation.

brendangregg 5y ago

I appreciate the discussion as I want to do a follow on post about this in more detail. It doesn't do the BPF community any good to have people running old broken versions of my tools (just as back in 2005, Sun was selling DTrace by distributing my half-finished socketsnoop.d). Now, some people are going to port anyway regardless of what's good for BPF. But if I can reach developers who may be on the fence about it, I can explain the pros of just building upon the existing tools. To start with, you get updates for free by kernel engineers at Facebook, Netflix, etc. Also, by pushing fixes back you'll find people will try to help you in return for when you need it (some startups, like Cilium, have done so much for BPF that I'd happily help them with anything they need (provided there isn't a clash with my current employment)).

kortilla 5y ago

> If I had to paraphrase the part of the post you're critiquing, I would do so as "If you're using these tools, don't feel like you have keep any stuff you do separate. We'd like to build something better for everyone, so feel free to contribute to the project rather than keeping it separate and we can all build on each other's work." That's pretty standard open source ideals IMO. Sure, that’s just a completely different writing of what’s actually there. The original post is an instruction not to do something. Your interpretation is a much more open “pull requests accepted”. His reply clarifies that he doesn’t want broken shit out there so your reading is incorrect. He does want to discourage forks because they are subtle to get correct and doesn’t want shit out their sullying bpf’s reputation.