A session on Open source software at Microsoft

Posted by Marcus Hammarberg on August 26, 2013
Stats
I got invited to do a Summer-session on Open Source from a developer perspective. It was my friend Dag König that invited me and I had great fun, both preparing and doing the session.
I even pulled of a demo of a life-time, in my opinion. We'll come to that later.
If you think about it the journey that OSS has done in the .NET and Microsoft community has been quite remarkable. Just a couple of years ago the words "Microsoft" and "Open source" could not be mentioned in the same sentence. Now you can fire up a virtual machine in Azure with Linux and the complete LAMP-stack on it. On top of that there's a number of prominent people promoting open source and alternatives to Microsoft recommendations and technologies - from within Microsoft.

That's cool in my book. It can be improved of course. But it's the start of the journey and I like it.
I got invited to do a Summer-session on Open Source from a developer perspective. It was my friend Dag König that invited me and I had great fun, both preparing and doing the session.
I even pulled of a demo of a life-time, in my opinion. We'll come to that later.
If you think about it the journey that OSS has done in the .NET and Microsoft community has been quite remarkable. Just a couple of years ago the words "Microsoft" and "Open source" could not be mentioned in the same sentence. Now you can fire up a virtual machine in Azure with Linux and the complete LAMP-stack on it. On top of that there's a number of prominent people promoting open source and alternatives to Microsoft recommendations and technologies - from within Microsoft.

That's cool in my book. It can be improved of course. But it's the start of the journey and I like it.

My journey

Since I'm by no means a authority on the history of the Open Source movement and it's history I told the story from my perspective. My journey begun a summer when I was the only one left at my current project. Since I didn't have much to do I thought I could try to teach myself something new. I had heard about build scripts and tried to create one. In order to accomplish this I had to use both CruiseControl.Net and NUnit.
This was the first time that I've used things and followed instructions that didn't came from Microsoft. It was (at the time) something that I didn't even considered before. But there and then I started my journey into taking input and ideas from other places than Microsoft.
Let me just say that I don't have anything against Microsoft. I like them - but I like my options as well. With more frameworks, more input, more opinions I have more to choose from.

The real history

Ok, the official history is pretty awesome too. But it's way to long to relate here. I learnt a great deal from these two wikipedia articles (Free Software movement and Open Source Initiative).
Here they are in condensed format:
Free software movement yada yada yada Richard Stalman, yada,  GNU (GNU's not Unix - haha!)  wanted to "create a operating system that was free from constraints on use of its source code", Linus Torvalds did that later, called it Linux, Eric Raymond wrote about it, coined the phrase open source.

There you have it: the condensed version of the early history of Open Source.
In the .NET community the advent of Alt.NET was really important to start people thinking about that thing that we use and things that we think doesn't HAVE to come from Microsoft. Although they (Alt.NET) in the beginning came out as an "-ism", against Microsoft - they eventually calmed down and became "an alternative to Microsoft".
For us these alternatives means that we have to be informed and make up our own mind on what's great and not. Where we before have been spoon-fed from Microsoft with what's good and not, we now have to form our own opinion. Something that at least for me has led to me learning more, improving my understanding and taking in more inputs.

Our session

The rest of the session was a whirlwind tour of tools and frameworks that I have used and learned about. It was done at break-neck speed but we actually got pretty good reviews, so something must have stuck.

NuGet

One of the tools that really opened a lot of door for open source in the .NET world was NuGet . It totally revolutionized how you manage external dependencies. Scott Hanselmann have a great bit on that in the first 5 minutes in this session. That contrast the before and after NuGet in a great way.
I talked about the only two commands you really need:
  • Install-Package XXX (don't forget to set the correct project!)
  • Uninstall-Package XXX (don't forget to do "-RemoveDependencies" or you'll end up in trouble).
We also talked about the benefits of "Enabling NuGet restore" to avoid checking in a lot of Mb with binaries.
Finally we had a discussion on when you should wrap the access to your external dependencies (if you think you'll ever need to replace the OSS framework for example) and why checking in the source code of an OSS framework into your repository is the worst of two worlds (you have responsibility to fix bugs and no support from the community).

Git

Since more or less every OSS framework use Git I thought it could be a great idea to introduce Git to the audience. They didn't though… so I kept it short. Very short.
But I have actually got by the last 3 years with just knowing 6-7 commands and understanding some simple facts about the git architecture.

Git is a distributed source control system, meaning that every developer have a complete copy of the repository. You clone the repository to get a local copy, of your own. In addition Git uses a staging area in which you "compose" a commit before you commit it into the repository.

Here are all the commands I know:
  • "git -?" and "git [command] -?" shows the help. And it's actually pretty good. "git branch -?" for example
  • "git clone [URL]" creates a local copy of a repository that you can work in. Git adds a link back to the repository you cloned as a remote repository called "origin". "git clone https://github.com/torvalds/linux.git" for example
  • "git checkout [branch]" branches are pretty ligthweight in Git and you find yourself switching between them often. This command does exactly that. If you add a "-b" to the command you create a new branch. This is useful when you start working on a new feature. "git checkout -b 'MyNewFeature'" for example
  • "git add [file]" and "git rm [file]" are commands that add and remove files to the staging area for your commit. With these command you build up your commit into a nice shape before you commit it into the repository. "git add --all" adds all your changes
  • "git status" shows how your staging area looks right now. This is run often. Like a ticks almost.
  • "git commit -m '[commit message]'" commits the changes in your staging area into your repository. Commit often. Very often. "git commit -m 'GetPersonFromDatabase tested'"
  • "git push [remote] [branch]" this command pushes the committed changes in your branch to the remote. For example "git push origin "MyNewFeature" pushes the changes committed into the MyNewFeature branch to the "origin" repository.
  • "git merge [branch] [branch]" merges the changes in one branch into the other branch. "git merge master MyNewFeature" merges the changes of "MyNewFeature" into "master"

Example frameworks

We rattled through a couple of frameworks and showed them off. Since I wanted to give a broad introduction I thought of a couple of categories and found some frameworks that I like. This made me realize that a lot of the things that you end up using is the thing that people you trust, you follow and you like are using. 
This is MY list - your might be better, but please tell me about it.
I created a repository for these examples here where I show how to use the framework.
Here's the list
  • Unit testing: xUnit and ShouldFluent
  • Dependency Injection: AutoFac (let the religious war begin…)
  • Web: NancyFx - of course
  • Data Access: Simple.Data - I might have called it "the ultimate solution to data access". And meant it.
  • Packages of packages: SuperDuperHappyPath this package helps you put together a stack of packages to write Nancy apps with (hosted on ASP.NET, with NDjango views and Simple.Data against MongoDb for example). I think this will become more common.
  • Datamapper: Automapper
  • REST API Client: RestSharp
  • We finally showed that Microsofts own templates in Visual Studio reaches out to NuGet to pull open source frameworks. WebApi and ASP.NET MVC are two examples

How do I know if it's any good?

This is a question that seems to trouble a lot of people that are new to using open source. Can I trust it? Will it stay around? Is it the best one? Questions like that. 

The simple answer is: you cannot know. You have to make an informed decision by yourself or by consulting others. Here is my list of things that I more or less conscious goes through when using a OSS framework (and some problematization around the metrics):
  • How does it look? Does it have a great web site? Is it easy to follow and understand the API? Do I get great first impression of the framework? I think this is super important and have often turned to another framework based on the simple fact that I didn't understand how to use the framework in under 30 seconds.  
  • What are the stats on GitHub (CodePlex, Google Code or whatever)? At GitHub there's a great tab called pulse (for Nancy for example) that gives you an overview of the activity.

    But is a lot of changes always good? What about "feature complete" frameworks? Is it bad that no changes are happening?
    There's also other stats that you should consider:
    • The number of forks - people have copies of this code
    • The number of stars - people likes this code
    • The number of watchers  - people are interested in news in this code
  • How many people are downloading it (on NuGet for example)? These stats tells me how much it's being used. But beware of the "operation"-aspect; now-a-days when a many people are restoring their packages from NuGet on build the numbers are WAY higher than the number of different people using it. Here's the stats from Nancy for example.

  • How is the documentation? Can I understand it? Is it well written? Is is updated?
  • What about the "web presence"; can you find it via Google? Are people interested by it on StackOverflow? Is there a chat somewhere? Does the creator tweet or blog? 

Summing up this means that you have to decide for yourself. There isn't one single source of truth. Now... this resembles something that I know... what can it be ... AHA! The real world! It's just like that. 

How to contribute back

The final part of my presentation was about giving back to the frameworks you are using. I think this is vital to get a active and living community. Besides it ties nicely back to the basic ideas and principles of open source

In this section it was live demos all along. I talked about the ways that you can contribute back and was demonstrating live on the Nancy project as we went along. 

File bugs and issues

One of the first and simplest thing you can do is to file issues, suggestions or bugs. On GitHub that's super simple with the issue creator. We created a simple issue for a improvement of one of the error messages from Nancy. 

Filing issues is simple since it's just reporting what you found. If you're feeling adventerous you could also add a failing test that proves your point. That makes the maintainers of the framework go crazy of happiness. I have done so a couple of times and that's been called "the best bug report I ever got" by some people.

Documentation

Write some documentation or update the existing documentation. Most OSS platforms (GitHub, Codeplex etc) have their documentation as a wiki so that anyone can update the documentation when they see the need. In many OSS frameworks the documentation is often out of date with the functionality of the framework. So just by updating the documentation you are doing them a big service. 

The "problem" with updating documentation is that you have to know what you are talking about, how the OSS framework works and should work and how to write about it. But this is your way into looking deeper in the functionality of the framework. I've learned a lot about Simple.Data when writing docs for them. 

At the session we updated the wiki-page on Model binding for Nancy. Live on stage. 

Pull requests

The final "level" in helping your favorite open source framework is to send them code and fixes. A lot of the things that I have sent in is fixing failing tests or get rid of warnings. And that have taught me enough to actually being able to add new features and fixes. 

Be sure to look into the code standards they are using and follow the instructions on how to do contribute to their repository. Don't feel sad if they send it back to you - this a great learning opportunity and, remember, that it's their code. 

In the session we did a pull request live on stage to fix the issue we reported before. Thanks to the great Nancy crew we also got our changed merged into the master-code repository while we waited! 

Best demo I ever did!

Summary

As always I learned a great deal about the topic (OSS in this case) while preparing for this presentation and while executing it.

For me OSS is now a vital and important part of my daily work. But that Microsoft is hosting an event on OSS is actually really cool. This is a changed approach from Microsoft and that change has happened fast - and continues to happen.

Get on the .NET OSS train - it's a good one!

PS.
Dag König has made a couple of podcast on OSS and some frameworks (Nancy and Simple.Data for example):




Published by Marcus Hammarberg on Last updated