Sure, lecture me on how DVCS work, it was obvious I didn't know.
The workflow you implement on top of DVCS, including how you manage branches, is completely context-dependent. No two organizations have the same approaches. You are probably confusing forking, branching and clones. Interestingly, excessive branching itself now tends to be considered less than ideal, but it again all depends on a team's specific workflow. There isn't just one.
The github link I gave shortly explains the two approaches you can use, and I explained numerous times why I favor the collaborator approach to the fork approach UNLESS you have a good reason to do it with forks. I have given my main reasons, which seem to be consistently ignored. Good, I just hope at least a few people have gotten my points. For the others, I don't care. And I have used DVCS for years, thank you. Using the collaborator model doesn't mean that you're not using git as a distributed system either. DVCS have a number of benefits over centralized systems even when not "forking". But I think the term "fork" has been largely abused here.
Again, while forking can be alright if you're actually working on say a feature that is far from being ready, that may not get accepted in the mainline for months, and, most of all, that several developers may work on in parallel, if it's just a convenience as a personal backup or even just as a sort of bookmark (as we said earlier), this just dilutes projects. The more forks, and the more the dilution - this point has nothing subjective about it, it's not opinion, it's just mechanically inevitable. And unfortunately, those cases seem to be the norm rather than the exception on github. This goes hand in hand with the excessive use, IMHO, of "cloud" storage as well. I haven't seen recent figures, but the ones I saw from a couple years ago showed a lot more forks than pull requests, and even fewer merges. That may raise a few questions about the efficiency of it all. And yes, it's probably obvious by now that I don't like github much. And that yes, you can absolutely use git or other DCVS on your own organization's terms, on your own servers, without breaking the spirit of DVCS.
Oh and a final thought related to this discussion. The most successful open-source projects have pretty much all used a form of vertical organization - the Linux kernel being a prime example - which is likely how they could become successful in the end. As Linux shows, the use of a DVCS is absolutely not contradictory to having some amount of vertical project management, and is still quite useful in this setting. Github, while promoting, whether they want it or not, the dilution of open-source projects, hinders vertical project management. Not saying it prevents it, but it makes it unnecessarily harder. Now, what happens, to be honest, is that many of the successful projects, even when they have a github repo, are primarily managed outside of github. And to get back to Brian here, even if it's a small project, what I've seen so far is that it's what he does. (IIRC, he has even stated on his github page to use this forum for any communication...
)