Subject: Microsoft github

From: "John R Levine" <[email-masked]>
Date: 4 Jun 2018 23:46:17 +0200

News reports say that Microsoft is buying github for about $5 billion. 
There's currently no reason to expect that Microsoft will change the way 
it works, and some reason to expect they won't since there are more github 
contributors from Microsoft than from any other organization (Facebook is 
second), but for people who have problems with their projects depending 
on a single large vendor, it's a single large vendor.

Bloomberg: https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
Financial Times: https://ftalphaville.ft.com/2018/06/04/1528114816000/Wot-is-Github/
Quartz: https://qz.com/1295693/github-users-already-fuming-about-companys-sale-to-microsoft/

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Kevin A. McGrail" <[email-masked]>
Date: Mon, 04 Jun 2018 23:50:01 -0400

Ross Gardler also at the asf has convinced me over years that Microsoft is very committed to open source.  I personally think it will improve things with github under their umbrella.  He shared an internal memo with the ASF that also helped.

Bccing him and perhaps he will share here.  At a minimum I am sure he would be interested to pass along concerns and questions.
Regards,
KAM

On June 4, 2018 5:46:17 PM EDT, John R Levine <[email-masked]> wrote:
>Bloomberg:
>https://www.bloomberg.com/news/articles/2018-06-03/microsoft-is-said-to-have-agreed-to-acquire-coding-site-github
>Financial Times:
>https://ftalphaville.ft.com/2018/06/04/1528114816000/Wot-is-Github/
>Quartz:
>https://qz.com/1295693/github-users-already-fuming-about-companys-sale-to-microsoft/
>
>Regards,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jun 2018 06:43:42 +0100

The only risk I can see in the situation is that Microsoft's usability team
might well fix the peculiar and confusing nomenclature used. It is
counter-intuitive to say the least to call comments on a version of a
document a 'pull request' when no document is being pulled.

On Tue, Jun 5, 2018 at 4:50 AM, Kevin A. McGrail <[email-masked]>
wrote:

> Ross Gardler also at the asf has convinced me over years that Microsoft is
> very committed to open source. I personally think it will improve things
> with github under their umbrella. He shared an internal memo with the ASF
> that also helped.
>
> Bccing him and perhaps he will share here. At a minimum I am sure he would
> be interested to pass along concerns and questions.
> Regards,
> KAM
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jun 2018 08:55:13 +0100

While I see no risk for the IETF in this acquisition, I do see a
considerable risk for Microsoft and the users of private repositories and
it is a risk I have been talking about for five years now, a risk I have
spent considerable time and effort designing technology to mitigate.

If I am a competitor to Microsoft, how can I have my development teams
upload mission critical software sources up to a service they control?

If I am Microsoft, how can I accept the risk of being accused of
malfeasance?

Note that I am absolutely not accusing Microsoft of anything bad here or
that this is an issue only Microsoft faces. Google has a vast exposure with
Google Docs.

There is a solution: Encrypt the data.

Can't do that with OpenPGP or S/MIME but the technology that does make that
possible went out of patent a few months ago. $7.5 billion for GitHub, how
about a modest side investment to develop the technology necessary to make
it viable?

On Wed, Jun 6, 2018 at 6:43 AM, Phillip Hallam-Baker <[email-masked]>
wrote:

> The only risk I can see in the situation is that Microsoft's usability
> team might well fix the peculiar and confusing nomenclature used. It is
> On Tue, Jun 5, 2018 at 4:50 AM, Kevin A. McGrail <
> [email-masked]> wrote:
>
>> Ross Gardler also at the asf has convinced me over years that Microsoft
>> is very committed to open source. I personally think it will improve things
>> Bccing him and perhaps he will share here. At a minimum I am sure he
>> would be interested to pass along concerns and questions.
>> Regards,
>> KAM
>>
>>

---

From: Denis Ovsienko <[email-masked]>
Date: Wed, 06 Jun 2018 11:32:04 +0100

---- On Wed, 06 Jun 2018 06:43:42 +0100 Phillip Hallam-Baker <[email-masked]> wrote ---- 
 > The only risk I can see in the situation is that Microsoft's usability team might well fix the peculiar and confusing nomenclature used. It is counter-intuitive to say the least to call comments on a version of a document a 'pull request' when no document is being pulled.
 > 

Below is my own opinion based on my own experience, you may find this input useful. One of the IT things I do is software development, I progressed from CVS to Subversion to git and have been using both externally-hosted and self-hosted repositories, bug trackers and similar services for quite a number of years.

"Pull request" is an established term in git workflow, GitHub before the sale had enough sense to use it properly. The simple reason for that was, git-based service was their only commercial business and GitHub had to get it right or to go home. They got it well enough back at the time, so when SourceForge dropped the ball really badly, its users had somewhere else to go, and the users did. So GitHub at a certain moment in time did their work much better than SourceForge, and SourceForge lost a significant user base to GitHub and other competitors, and that was fair and the change has been driven by a more or less normal feedback loop up to now.

Someone in Microsoft now may have an idea of their own, and suddenly claim pull requests on github.com are now not pull requests but "Microsoft collaboration review 2018 professional edition" or any other random string. However, given the established terminology such change would be an opposite of a fix. The problem is, Microsoft can make far more damage than this simple example, and had done that before so many times, and can do that again, because if Microsoft runs GitHub into the ground, they can just quickly drop it, grab the next toy and pretend nothing happened. The feedback loop is now broken for GitHub.

What it means for IETF depends on whether individual IETF contributors understood the properties of the two tools they used.

One tool is the git distributed version control system. It is a professional tool, it has its terminology, properties, implied workflow and intended use. Using a git repository for distributed version control is generally a good idea and provides (assuming proper use) a lot of redundancy, integrity and other good properties for long-term project survival.

github.com is (in plain technical language) a proprietary software made available online. It runs on top of git repositories and blends non-repository data with repository data very successfully. On one hand, it makes everyday work much easier to do. On the other, many users do not realize their projects, milestones, bug reports, comments and pull requests only exist on GitHub servers, and if suddenly that sole copy is gone (for whatever real world reason), the users can direct themselves to a copy of the EULA. When happens, this stops normal work and may even impact a project survival.

To sum it up, git is fine for its intended use, github.com is fine for its intended use, the fact GitHub is now about to lose its feedback loop is a perfect time for IETF GitHub users to check they have used each tool for its intended purpose, have committed all meaningful permanent bits of information into meaningful repositories and mirrored them on an IETF server. As a rule of thumb, if the list of meaningful git repositories does not exist, that's the first thing to put right.

-- 
    Denis Ovsienko

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Wed, 6 Jun 2018 09:52:26 -0400

> upload mission critical software sources up to a service they control?

If you are talking about software stored on internal, closed source
repo's, (a) why can't you run your own internal git server --- it
really isn't *that* hard, and (b) why did you trust github before its
acquisition by Microsoft --- especially if it is "mission critical
software sources"?  There is a *reason* why all of the major software
companies --- Google, Amazon, Microsoft, etc., maintain their own
source control systems which live inside the corporate firewall.

If you are talking about software intended for public distribution or
cooperating development using an open source license, git is a
decentralized repository with digital signature support (for tags and
commits).  So there's nothing evil Microsoft can do, assuming
developers who have a clue.  And if they don't and they accept the
wrong pull request from putinIzGreat.kremvax.ru, you're sunk anyway.

This is nothing new.  If you have clueless users who are willing to
say, "Hurr, Durr, I opened my e-mail and a password prompt showed up
--- guess I'll enter my password into that nice phishing web site",
there's not much you can do to protect your corporate security,
whether you're a Fortunate 500 company or the DNC.

    	    	    	  	 	    		- Ted

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 6 Jun 2018 11:21:27 -0400

> really isn't *that* hard, and (b) why did you trust github before its

I think this point is important: "why would anyone have trusted github?"
or their employees really... certainly "any" (some, not all) github
employees could have had access to all of the repositories (public/private)
and copied away relevant bits on demand... Changing the label on the
employee's shirt isn't really changing the equation.

---

From: Nico Williams <[email-masked]>
Date: Wed, 6 Jun 2018 13:36:34 -0400

> employee's shirt isn't really changing the equation.

Lots of organizations trust third parties with sensitive content.  Usually
one uses contracts to get desired assurances and recourse to the courts.  A
contractually-bound third party is like yet another insider.  The risks may
or may not be higher than insider risk, depending on lots of specific
details.

Nico
--