5 ms·
> As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem. Forks because the main project is not respo
by kbenson 5y ago
> As someone who has spent a lot of time in open source, forks are not a problem, they are indicative of a problem.
Forks because the main project is not responding to a need are not a problem. Forks just because some project or product believes it gives them more control and they don't interface with the original project usefully are a sort of a problem. Those aren't necessarily started because of a community need, but some business need or perceived business need which may have nothing to do with the reality.
I think that's the situation he's asking to avoid here, as he mentions observability products. He's saying please don't fork just to have it under your own repo and for no other reason, when it can be developed jointly.
- kortilla 5y agoWhy? If someone wants more control their interests already aren’t aligned with the community. Developer resources aren’t just some faucet easily redirected. It’s worse to have people trying to jam shit into the main project if they don’t actually care about the main project. 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. 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. git is an incredible tool for managing forks and this anti-fork mindset is right out of old school open source culture from the early 2000s. Demanding people contribute to your project instead of forking just sounds like demands to pay homage more than anything.
- kbenson 5y ago> 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 agoI 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.