[sr-dev] Slightly wacky suggestion...

[Alex Balashov]

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

-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/