Hacker News Reader

I would say the same about github's forks-as-top-level-entities system.

Forking a project is a huge deal. Forking a git repository is no big deal.

Github does the former, and it encourages too-broad forks, and at the same time, discourages coordination and contribution with the original project. Nearly all forks should be short-lived and completely subsidiary to the main project.

View on HN

While many projects / companies work as you say, the linux kernel development model has always been much more like how github does forks. Git was designed to be truly distributed and de-centralized, although many people choose not to use it that way.

That's a lot of opinions and much less arguments (no offense). Would you care to explain the motivations behind the opinions?

Forks -- as top-level named entities -- draw attention and resources away from the original project, possibly leaving both projects with too-few resources to survive afterwards.

This is why "forking" an open-source project was considered a nuclear option prior to the emergence of github.

I rarely even get pull requests from people forking my code on github, and when I do, they almost never have bothered to discuss with me prior to implementation. It's a relatively recent phenomena that is largely encouraged by the tools.

Reply on news.ycombinator.com