Hello Peter,
Admittedly, I am not intimately familiar with GitHub. But, of course, I have interacted with it in my use of numerous open-source projects hosted there (beyond just checking out
Not to say that I know best, because I don't, but:
On 08/29/2013 12:29 PM, Peter Dunkley wrote:
- The GitHub concept of forking would make individual developers branches easier to manage.
How so? (I am not familiar with the GitHub concept of forking.)
- The GitHub concept of forking and push-requests would make it easier for people who are not core developers to submit patches and for the core developers to review them and apply them.
Admittedly, that would be attractive.
- People have been complaining about flyspray for a while and the GitHub tracker is nicely integrated into the repository making it easy to relate issues to code and patches.
Yes, but it would be practical or easy to migrate the existing Flyspray requests to that tracker? And does the tracker really command a substantial usability premium over Flyspray, or is this a matter of custom, habit and taste?
- The GitHub web-UI means that the code is easier to browse, inspect, view history (and relate changes to issues) than the "default" Git one that is in use at the moment.
I do believe that is a matter of custom, habit and taste. For instance, I am much more accustomed to Gitweb (the current UI) and appreciate it for its simplicity and lack of clutter related to GitHub's "collaborative" accoutrements and embellishments. I find it more difficult to navigate GitHub's layout, and I can't be the only one.
- There would be no need for anyone to spend time or money maintaining/patching/fixing the SIP Router Git repo and flyspray.
The fact remains that the hosting is already provided in a professional manner by Kamailio's biggest corporate sponsor.
Moreover, as always, running one's own repo and bug tracker opens up more possibilities for backend automation and integration with third-party tools. Of course, Git is Git, and I'm sure GitHub has some useful APIs, too, and it is likely that the project probably won't be needing such advanced integration in the near future.
Still, it's always a trade-off when switching to a "cloud" service. Control is good.
- Someone else is handling backups and failure recovery.
Somehow I suspect that is also the case currently.
- The use of markdown means that documentation and code can be presented together in a nice way with GitHub.
Yes, but Kamailio has an existing documentation presentation mechanism and a content engine for that purpose (Dokuwiki).
Also, although Olle's point about concentration vs. decentralisation of the Internet is a bit more abstract, it resonates. In general, I think most of the technically-minded among us can agree that there are some deeply worrisome side effects from the lopsided concentration of e-mail services--and the physical control of e-mail servers--into the hands of Google, for instance. The substantial monopoly of online socialisation enjoyed by Facebook is equally disconcerting. This seems to have deleterious effects from the point of view of privacy and government surveillance, not to mention the ever-present problem of our eyeballs and attention spans being sold for marketing dollars.
Now, obviously, privacy is not a concern for a public-facing open-source project. However, there is a common thread of philosophical concern here that we should probably heed.
The arguments--related to workflow streamlining, economies of scale, and divestiture of non-core competencies--for "cloud services" are well-understood, and often make economic sense. However, they should be balanced against the reality that putting the project in GitHub puts the tools we use to develop it squarely in GitHub's control, and, in a very real sense, subjects us to the whims of GitHub, to the business objectives motives of GitHub, and to the very same of GitHub's prospective future investors or as-yet-unknown future owners.
We become a very small fish in a very big sea that moves according to tides we don't control. That is, of course, the reality of virtually all economic interdependence and civilisational complexity, but I think we should carefully think about whether following the current "cloudy" fashions--together with the nice feature set on offer at GitHub, no doubt about it--is really in the best interests of the project.
-- Alex