Microsoft, GitHub, and the Power of Corporate Support of Open Source

Let me start by saying that I’m a massive advocate, contributor, and supporter of many open source communities, while also working in my role for a technology vendor who provides a commercial product that also supports many open source platforms.  The reason that matters is that I’m not saying this without an understanding of the inner workings of both the open source community (people), the contribution process for code, sponsorship, and more (process), as well as a growing knowledge of implementations and architectures which use and contribute back to open source tools (technology).

There is news (technically a rumor until a few hours from when this posts which will confirm the news), that Microsoft is buying GitHub.  What is also happening is the unfortunate rise in negativity around this purchase.

  • Microsoft contributes heavily to open source products
  • Microsoft staffers are also strong contributors personally to many open projects
  • Microsoft is using open source GitHub to create their own open source products!

What interest does Microsoft have in buying GitHub?  Well, to start with, how about the exact same interests that the GitHub founders and investors have, which is to build a platform which (as the mission statement said) is designed around people and the way the collaborate:

Code is about the people writing it. We focus on lowering the barriers of collaboration by building powerful features into our products that make it easier to contribute (GitHub Mission Statement – partial)

Nothing in there about being 100% open and never being bought by a large technology vendor, right?

Corporate Support is a Significant Factor in Open Source Growth

Many projects have succeeded, or at the very least gotten larger access to resources in order to grow as a result of great companies like Microsoft, Cisco, Google (Ummm Kubernetes anyone?), RackSpace, Juniper Networks, VMware, and others.  That support come in sponsorship of foundations that help us collaborate as an organization, for event hosting, meetups, and paying for developers to be able to contribute time to open source projects while being paid by these very vendors.

I won’t go further with justification or details.  You can easily research the adoption lifecycle and see where corporate support entered in, and where broader adoption occurred.  Even projects which may appear to not be influenced by “big tech” vendors have been supported by letting developers contribute their time, code, and advocacy, while those developers and evangelist/advocates are paid by Microsoft, Google, AWS and other vendors.

Microsoft today is not the Microsoft of the past.  Even Microsoft of the past was probably pale in comparison to what some other big vendors who are lauded for open source support have done which is counter to the apparent interests of open communities.

If you feel the need to get your code off of GitHub because Microsoft is buying them, I’m afraid you may not realize how much corporate backing is heavily responsible for the success of open source products, including the very ones you may be creating.

Sorry for the rant.  Happy to take this conversation with anyone to a podcast if you have strong opinions on it 🙂



Run the AWS Shell Quickly and Easily in a VirtualBox Instance Using Vagrant

Because we like the Martha Stewart pre-baked oven version of things, this is the shortcut to running the AWS CLI without having to dirty up your own local environment.

Why use a Sandbox?

While development entirely using your local machine is handy, there can often be configuration issues, and also conflicts with other development libraries. In my earlier post, you saw how to configure a basic sandbox environment. I’m assuming that you’ve already got the following installed as documented in that post:

  • Git client
  • Vagrant
  • VirtualBox

This is how to deploy and configure the AWS Shell environment using a sandbox server in just a couple of simple steps!

Clone the GitHub Repo

From your command line, you can just run a git clone to get ready with all the Vagrant code:


Next, we change into the directory and we run a vagrant status to confirm that the configuration is ready to run:


We can see that it says not created for the machine, so let’s run vagrant up and get this party started!


Once the process is completed, you will see this message:


What’s in the GitHub Repo to make AWS CLI work?

The basic build of a sandbox machine was documented in my previous post, and the secret sauce for this is really quite easy. The only reason I like this approach is that I have a super simple deployment of a purpose-built machine to test out AWS CLI work. All with two simple statement:

sudo apt-get install -y python-pip sudo pip install aws-shell

Yes, it is just that easy.

Once the machine completes the installation, you are ready to log in to the console and give it a try. We do this by running vagrant ssh awssandbox:


Et voila! You are now ready to start up the AWS shell.

Configuring and Running AWS Shell

The environment is all installed. Now, we need to run our AWS shell which will do some basic configuration at the first launch:


After the console comes up (it takes about 30 seconds to build the autocomplete cache), we have to configure it to use our AWS credentials.

When we start to type the configure command which you will see does an autocomplete:


The three pieces of information you need to configure the AWS shell are your Access Key, your Secret Access Key, and the Region name you are working within. Just like with the web client, you have to choose a default region to explore. That can be changed again at any time by re-running the configure command:


We are all set with our configuration, and you can start typing away on the AWS shell commands. There is an autocomplete function on everything, and you can even scroll up and down when the autocomplete suggestions come up:


For example, we can list the regions by using the ec2 describe regions command that outputs a JSON response of the available regions:


We can also use the ec2 describe instances command to list out any active instances that are in this region under our account:


The output will span a couple of screens in a prompt window, but luckily we can scroll up or down and also copy the content out from the shell to evaluate in a text editor if you so desired.

There are literally hundreds of commands, but the main thing we wanted to see here was how to just get the basic configuration up and running so that you can start exploring.

To exit, you can use F10 or Ctrl-D to go back to the Linux shell prompt.

Now you have your AWS shell environment ready to save and reuse as needed without having to deploy anything on your home environment. Another advantage is that you can snapshot this one, run it on any platform that supports VirtualBox, and not worry about versioning or anything at all with dependencies at the OS level.

Updating Forked Git Repository from Upstream Source (aka Rebase all the things!)

As you can imagine, the world of IaC (Infrastructure-as-Code) means that we are going to have to dabble a lot more in the world of code repositories. Git is the most common tool I have found in use for code version control, and along with it, is the most common place that people (including myself store their project code.

All Forked Up

When the first work happens with using Github is that you may find yourself forking a repository to create a point-in-time snapshot under your own repositories. This is done for a variety of reasons like contributing upstream code, and keeping a “safe” stable release of a particular codebase that could change and affect other work you are doing with it.


As you can see in the image above, I have a forked copy of the Lattice framework from Cloud Foundry. Nice and easy to do, but as you look at the bottom of the image, you will also see that I’ve been falling behind on updates.


So, how does someone fix this situation? Let’s assume that we are testing locally and find a bug, but then realize that the upstream repository has already fixed the bug. Rather than wiping out the repository altogether and re-cloning, let’s fix it in place!

Updating a Forked Repository from Upstream Source

Let’s jump in the command line, and see what’s happening. In my lattice folder, I will do a git status to see the current state of things:


We can see that we show as up to date, but I know that I am 649 commits behind the upstream source. Time to get ourselves up to date for real.

The way we do this is by syncing up our repositories here locally, and then pushing the changes back up to our forked repository. First, let’s check our remote source by typing git remote to see what’s happening locally:


We have one source called origin which is our forked repository. We are going to add one more source called upstream to point to the original repo using the command git remote add upstream in my case and then run our git remote again to confirm the change:


Now we can see both of our sources. We are assuming that you are using the master branch of your repo, but just in case, we can also do a git checkout master first for safety. As you can see in my case, it will complain that I am already on ‘master’ and nothing will happen:


Now let’s do the next steps which is to fetch the upstream and rebase our local repo. Yes, these are funny sounding terms to some, but you will get used to them. This is done by using the git fetch upstream command followed by the git rebase upstream/master to sync them up:


Lots of updates came down, and you can see that our rebase has done all the changes locally and if we had any updates, they would be left in place with the underlying repo updates done at the same time.

We need to check our status first using the git status and as you can see here, it will show the 649 commits ahead of origin/master which is my forked repo on Github:


Now it’s time to push all the updates! This will commit the changes to the Github forked repo for you and then we are up to date with the upstream source. We will use the git push origin master which pushes the local changes to the master branch of our origin source (in our case discoposse/lattice) and then we can confirm the changes are committed with a git status afterwards:


There you go! Now your forked repository is up to date with the upstream source and you can get back to the coding!

If you check your Gitub page also, you will see the change there:


Hopefully this is helpful, because I have been asked a few times recently about dealing with this issue as people get started with Git. I hope to bring some more quick Git tips as I hear questions come from the community, so feel free to drop me a comment with any question you have!