On Jun 7, 2017, at 10:37 AM, Stephen Chrzanowski <pontia...@gmail.com> wrote: > > You can't be 100% certain that GitHub is going to > be online tomorrow
As well, we have plenty of history showing that we can’t trust the long-term availability or trustworthiness of third party hosting services. Major examples are Sourceforge and Google Code in this section of the software universe, and we have lots of examples in other areas if those two aren’t enough. > 21st century or not, > he's not a lemming and doesn't have to jump on the next bandwagon. The Fossil project was started in 2006, so it’s a 21st century solution, by definition. :) > As for the comment about registration, you need to register to get onto > GitHub as well. Weeeelll, that’s not really the OP’s point, now is it? The real distinction is that GitHub doesn’t care about your actual identity, just that you can be proven to exist somewhere on the Internet in a uniquely identifiable fashion. According to GitHub, there are two “Warren Young” entities who both happen to live in my house. :) One of them more often logs in from that house and the other most often logs in from $dayjob’s computers, but they’re the same person, and GitHub doesn’t know it. Fossil, on the other hand, is for projects where all of the developers are expected to know each other at some personal level before they join; maybe not by face, but certainly by reputation. There is no “Fork me on Fossil”, on purpose. Semi-anonymous forks hurt project cohesiveness. In theory, GitHub allows one of the forks to emerge as dominant, pulling in changes from more other forks than the others, but more often I see bunches of semi-private forks on GitHub, with no hope that the forked versions will ever merge changes back upstream. They might as well be private checkouts with local modifications for all the value this sort of forking provides. In absence of a strong central project, you end up with multiple versions all holding the same weight, according to GitHub, with no way for the end user to select among them. I know I’ve personally Googled some project and been mislead to someone’s private GitHub mirror of it, simply because GitHub has so much Google juice that it often outranks the actual source of the project. If there are multiple mirrors in GitHub, you won’t even know that they’re all non-canonical. The “Fork me on GitHub” model is also fundamentally mismatched with respect to projects like Fossil and SQLite where formal license grants (Fossil) or license disclaimers (SQLite) are required before changes can be merged into the master project. Repository login grants in such a project are actually just a formality gated by the real gatekeeping mechanism, that being the signed contributor agreement. Bottom line, Fossil is perfectly suited to SQLite’s needs, as it should be, given that it was created to serve it. Fossil is also great for other projects of its sort: small to medium sized project managed by a small, cohesive group. Git-style distributed development is better for non-cohesive projects, or for those so large that Git’s complexity-bought advantages start to pay off. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
