GitHub Drinkup MVP Edition

Next week Microsoft hosts its annual MVP Summit. So what better time for me to host my first GitHub Drinkup – MVP Edition at the Tap House Grill!

Not an MVP? Nonsense! You are in my book, so show up! If you are an MVP, you’re still welcome to slum it with the rest of us schlubs.

All the details are posted over at the GitHub Blog post.

What is a “Drinkup” you ask?

It’s pretty simple. It’s a meetup where we drink and share stories of valor in the face of code complexity. Or jabber on about whatever else software developers want to geek out about.

Getting together and sharing a brew or two is deeply ingrained in the GitHub culture. After all, GitHub was conceived over a beer at a bar.

If you’re not in the Seattle/Bellevue area, GitHub hosts a monthly (more or less) drinkup in San Francisco where the GitHub HQ is located. We also host the occasional drinkup all over the world when we attend conferences in various locations.

So come on out, unwind, and let me buy you a beer. Perhaps this drinkup will be the one where you’ll meet your next cofounder. At the very least, you’ll enjoy some good drink and good conversation.

.NET Startup Group March 8

And if you can’t come out on Tuesday, I’ll also be speaking at the .NET Startup group on March 8 on GitHub, Git and making it all work on Windows. I might throw in a dash of NuGet in there since I can’t help myself. There’s still plenty of seats available.

What Is The Spirit of Open Source?

In my previous post, I attempted to make a distinction between Open Source and Open Source Software. Some folks took issue with the post and that’s great! I love a healthy debate. It’s an opportunity to learn. One minor request though. If you disagree with me, I do humbly ask that you read the whole post first before you go and rip me a new one.

It was interesting to me that critics fell into two opposing camps. There were those who felt that it was was disingenuous for me to use the term “open source software” to describe a Microsoft project that doesn’t accept contributions and is developed under a closed model, even if it is licensed under an open source license. Many of them accepted that, yes, ASP.NET MVC is OSS, but I still shouldn’t use the term.

While others felt that the license is the sole determining factor for open source and I wasn’t helping anybody by trying to expand the definition of “open source.” To my defense, I wasn’t trying to expand it so much as describe how I think a lot of people use the term today, but they have a good point.

Going back to the first camp, a common refrain I heard was that software that meets the Open Source Definition might “meet the letter of the law, but not the spirit of the law” when it comes to open source.

Interesting. But what is the “spirit of open source” that they speak of? What is the essential ingredient?

Looking For The Spirit

I assume they mean developing in the open and accepting contributions to be necessary ingredients to qualify a project as being in the spirit of open source. I started to dig into it. I expected that we should probably see references to these things all over the place when we look up the term “open source”.

Oddly enough, Wikipedia doesn’t really talk about those things in its article on Open Source, but hey, it’s Wikipedia.

But oddly enough, there’s no mention of accepting contributions in the Open Source Definition or pretty much anywhere in http://opensource.org/ that I could find. It doesn’t really address it.

Neither does any open source license have anything to say about the way the software is developed or whether the project accepts contributions.

Let’s take a look at the Free Software Foundation which is opposed to the term “Open Source” and might have a different definition of free software. I’m going to quote a small portion of this.

Thus, “free software” is a matter of liberty, not price. To understand the concept, you should think of “free” as in “free speech,” not as in “free beer”.

A program is free software if the program's users have the four essential freedoms:

• The freedom to run the program, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help your neighbor (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

I looked for interviews from the pioneers of open source for more information. Richard Stallman reiterates the same points in this interview. What about Eric Raymond? Well he just links to http://opensource.org/. As you can see, he’s the President Emeritus of the Open Source Initiative (OSI) which created the OSD that I’ve been using as my definition.

I then asked Miguel De Icaza for his thoughts. Miguel is a developer with a long history in open source. He started the GNOME and Mono projects and has more open source experience in his pinky than I have in my entirety. He had some interesting insights.

In general, I am not sure where the idea came from that for something to be open source, the upstream maintainer had to take patches, that has never been the case.   Some maintainers are just too protective (qmail I believe for a long time did not take patches, or even engage in public discussions).   Others are just effectively too hard for average developers to get patches in (Linux kernel, C compilers) that they are effectively closed.

What gives?

Isn’t it odd that these concepts that we hold so dearly to as being part of the spirit of open source aren’t mentioned by these stewards of open source?

Maybe it’s because the essential ingredient to open source, the spirit of open source, is not accepting contributions, it’s freedom.

The freedom to look at, remix, and redistribute source code without fear of recrimination.

Even so, I still think accepting contributions and developing in the open are hugely important to any open source project. If I didn’t believe that, I wouldn’t be working at GitHub.

I started to think that perhaps a more apt term to describe that process is crowd sourcing. Crowd sourcing can provide many benefits, according to the article I linked to:

• Problems can be explored at comparatively little cost, and often very quickly.
• Payment is by results or even omitted.
• The organization can tap a wider range of talent than might be present in its own organization.
• By listening to the crowd, organizations gain first-hand insight on their customers' desires.
• The community may feel a brand-building kinship with the crowdsourcing organization, which is the result of an earned sense of ownership through contribution and collaboration.

But Miguel thought a better term is “open and collaborative development.” That’s the process that is so closely associated with developing open source software that it’s become synonymous with open source in the minds of many people. But it’s not the same thing because it’s possible to conduct open and collaborative development on a non-open source project.

Splitting Hairs?

I know some folks will continue to think I’m splitting hairs, which is an impressive feat if you think about it as I definitely don’t have the hands of a surgeon and hairs are so thin.

One counter argument might be that perhaps the original framing of “open source” was focused on freedoms, but what we refer to as open source today has evolved to include crowd sourcing as an essential component.

I can see that. It seems obvious to me that collaborative development in the open is a huge part of the culture surrounding open source. But being a core part of the culture doesn’t necessarily mean it’s in the spirit. A lot of people feel that drugs are a big part of the Burning Man culture, for example, but I don’t think it’s an essential part of its spirit. It’s the creativity and expression that forms the spirit of Burning Man.

Who Cares About The License?

Another point someone made is that the community of contributors is more beneficial than having an open source license. I addressed that point in my last post, but Miguel had a great take on this, emphasis mine.

The reason why the OSI definition was important is because it provided a foundation that allowed unlimited redistribution and serviceability for the code for the future, with the knowledge that there were no legal restrictions.  This is the foundation for Debian's policies and in general, the test that must be passed for a project to be adopted.  Serviceability does not require talking to an upstream maintainer, it means having the means and rights to do so, even if the upstream distribution goes away, vanishes, dies, or moves on to greener pastures.

You could build the most open and collaborative project ever, but if the source code isn’t under a license that meets the open source definition, it may be possible for project to close shop and withdraw all your rights to the code.

With OSS code, that’s just not possible. A copyright holder of the source can close shop and stop giving you access to new addition they write, but they can’t retroactively withdraw the license to code they’ve already released under an OSI certified license.

And this is a real benefit, even with otherwised “closed” projects that are open source. Miguel gave me one example in relation to Mono.

A perfect example is all the code that we have taken from Microsoft that they open sourced and ran with it. In some cases we modify it/tweak it (DLR, BigInteger), in others we use as-is, but without it being open source, we would be years behind and would have never been able to build a lot of extra features that we now depend on.

Prove me wrong?

By the way, I’m open to be proven wrong and changing my mind. Heck, I’ve done it twice this week as Miguel convinced me that “Open Source” only requires the license. But if you do disagree with me, I’d love to see references that back up your point as opposed to unsubstantiated name calling.

I think this topic is tricky because it’s very easy to discuss whether software is licensed under an open source license. If we agree on the open source definition, or the free software definition, you can easily evaluate that yes, the software gives you the rights and freedoms mentioned earlier.

But it’s trickier to create strict definitions of what encompasses the spirit of anything, because people have different ideas around them. I know some folks that feel that commercial software goes against the spirit of open source. I tend to disagree pointing out that it’s the license that matters, and whether or not you make money from the software is tangential. But I digress.

I know I won’t convince everyone of my points. That’s fine. I enjoy a healthy debate. The only thing I hope to convince you of is that even if you disagree with me, that you can see I’ve provided good reasons for me to believe what I do and it’s not out of being disingenuous.

Collaboration is Good

In the end, I think it’s a huge benefit for any open source project to develop in an open collaborative manner. When I think of open source software, that’s the development model that comes first in my mind. But, if you don’t follow that model (perhaps for good reasons, maybe for bad reasons) but do license the software under an open source license, I will still recognize your project as an open source project.

Open Source and Open Source Software Are Not The Same Things

UPDATE: I have a follow-up post that addresses a few criticisms of this post.

It all started with an innocent tweet asking whether ASP.NET MVC 3 is “open source” or not? I jumped in with my usual answer, “of course it is!” The source code is released under the Ms-PL, a license recognized that the OSI legally reviewed to ensure it meets the Open Source Definition (OSD). The Free Software Foundation (FSF) recognizes it as a “free software license”¹ making it not only OSS, but FOSS (Free and open source software) by that definition.

Afterwards, a healthy debate ensued on Twitter. No seriously! “Healthy” debates on Twitter do happen sometimes. And many times, I learn something.

Many countered with objections. How can the project be open source if development is done in private and the code is “tossed over the wall” at the end of the product cycle under an open source license? How can it be open source if it doesn’t accept contributions?

This is when it occurred to me:

1. I’ve been using these terms interchangeably and imprecisely.
2. Many people have different concepts of what “open source” is.

“Open source” is not the same thing as “open source software”. The first defines an approach to building software. The second is the end product. Saying they are the same thing is like saying that a car that Toyota makes and Kanban are the same thing. Obvious, isn’t it?

The Importance of Definitions

I’m a big fan of open source software and the open source model of developing software. I don’t necessarily think all software should be open source, but I do find a lot of benefits to this approach. I’m also not arguing that writing OSS in a closed off manner is a good or bad thing. What I care about is having clear definitions so we’re talking about the same things when we use these terms. Or at least making it clear what I mean when I use these terms.

Definitions are important! If you allow for any code to define itself as “open source”, you get the monstrosities like the MS-LPL. If you don’t remember this license, it looked a lot like an open source license, but it had a nasty platform restriction.

Microsoft started the term “Shared Source” to describe these licenses which allow you to look at the code, but aren’t open source by most common definitions of the term.

Open Source Software

Going back to my realization, when I talk about “open source” I often really mean “open source software”. In my mind, open source software is source code that is licensed under a license that meets the Open Source Definition.

Thus this phrase is completely defined in terms of properties of the source code. More specifically, it’s defined in terms of the source code’s license and what that license allows.

So when we discuss what it means for software to be open source software, I try to frame things in terms of the software and not who or how the software is made.

This is why I believe ASP.NET MVC is OSS despite the fact that the team doesn’t currently accept outside contributions. After all, source code can’t accept contributions. People do. In fact, open source licenses have nothing to say about contributions at all.

What defines OSS is the right to modify and freely redistribute the code. It doesn’t give anyone the right to force the authors to accept contributions.

Open Source

So that’s the definition that’s often in my mind, when I’ve use the term “open source” in the past. From now on, I’ll try to use “open source software” for that.

When most people I talk to use the term “open source”, they’re talking about something different. They are usually talking about the culture, process, and philosophy that surrounds building open source products such as open source software. Characteristics typically include:

• Developed in the open with community involvement
• The team accepts contributions that meet its standards
• The end product has an open source license. This encompasses open source software, open source hardware, etc.

There’s probably others I’m forgetting, but those three stand out to me. So while I completely believe that a team can develop open source software in private without accepting contributions, I do believe that they’re not complying with the culture and spirit of open source. Or as my co-worker Paul puts it (slightly modified by me)

I would put a more positive spin, that they're losing out on many of the benefits of open source.

And as Bertrand points out in my comments, “open source” applies to many more domains than just software, such as open source hardware, recipes, etc.

Why does it matter?

So am I simply quibbling over semantics? Why does it matter? If a project does it in private and doesn’t accept contributions, why does anyone care if the product is licensed as open source software?

I think it’s very important. In fact, I think the most important part is the freedom that an open source license allows. As important and wonderful as I think developing in the open and accepting contributions is, I think the freedom the license gives you is even more important.

Why? Maybe a contrived, but not too far fetched, example will help illustrate.

Imagine a project building a JavaScript library that develops completely in the open and accepts contributions. They’ve built up a nice healthy ecosystem and community around their project. Some of the code is really whiz bang and would make my website super great. I can submit all the contributions I want. Awesome, right?

But there’s one teensy problem. The license for the code has a platform restriction. Let’s say the code may only run on Windows. That’d be pretty horrible, right? The software is useless to me. I can’t even use a tiny part of it in my own website because I know browsers running on macs will visit my site and thus I’d be distributing it to non-Windows machines in violation of the license.

But if it were a library developed in private, and once in a while they produce an open source licensed release, so many doors are opened. I can choose to fork it and create a separate open community around the fork. I can distribute it via my website however I like. Others can redistribute it.

Again, just to clarify. In the best case, I’d have it both ways. An open source license and the ability to submit contributions and see the software developed in the open. My main point is that the license of a piece of useful software, despite its origins, is very important.

In the end?

So in the end, is ASP.NET MVC 3 “open source”? As Drew Miller aptly wrote on Twitter,

How I like to describe it: ASP.NET MVC 3 is open source software, but not an open source project.

At least not yet anyways.

UPDATE: After some discussion, I’m not so sure even this last statement is correct. Read my follow-up post, What is the spirit of open source?

¹Although the Free Software Foundation recognizes the MS-PL (and MS-RL) as a free software license, they don’t recommend it because of its incompatibility with GNU GPL.

Changing A Strong Name Is A Major Breaking Change

Recently, the Log4Net team released log4net 1.2.11 (congrats by the way!). The previous version of log4Net was 1.2.10.

Despite which version of version you subscribe to, we can all agree that only incrementing the third part of a version indicates that the new release is a minor update and one that hopefully has no breaking changes. Perhaps a bug fix release.

This is especially true if you subscribe to Semantic Versioning (SemVer) as NuGet does. As I wrote previously,

SemVer is a convention for versioning your public APIs that gives meaning to the version number. Each version has three parts, Major.Minor.Patch.

In brief, these correspond to:

• Major: Breaking changes.
• Minor: New features, but backwards compatible.
• Patch: Backwards compatible bug fixes only.

Given that the Patch number is supposed to represent bug fixes only, NuGet chooses the minimum Major and Minor version of a package to meet the dependency contstraint, but the maximum Patch version. David Ebbo describes the algorithm and rationale in part 2 of his three part series on NuGet Versioning.

Strong Names and Versioning

The consequence of this is as follows. With the new log4Net release, if you have a package that has log4net 1.2.10 or greater as a dependency:

<dependency id="log4net" version="1.2.10" />

Installing that package would give you log4net 1.2.11. In most cases, this is what you want because the newer release might have important bug fixes such as security fixes.

However, in this case, Log4Net changed the strong name for their assembly for 1.2.11. Whatever your feelings about using strong names or not (that’s a separate discussion), the fact is that if you choose to use them, changing the strong name is changing the identity of your assembly. That’s a major breaking change.

And man, were a lot of people affected! We heard from tons of folks who were broken by this and unsure how to fix it.

NuGet does support a workaround so that you can prevent inadvertent upgrades. You can constrain the allowed versions of an installed package by manually modifying packages.config. Sadly, we don’t yet have a UI for this, so it’s a bit of a pain.

The Solution

Apart from never changing your strong name, the solution in this case is to treat this change as a major breaking change and increment the major version number of the assembly.

I don’t anticipate the Log4Net team will change the version of their assembly, but I reached out to the maintainer of the Log4Net package (no connection to the Log4Net team so please don’t give him grief about this) and he graciously incremented the major version of the Log4Net package to solve the problem.

Just to be clear, the log4net 2.0 NuGet package contains the log4net 1.2.11 assembly.

While it’s generally good form to have the package and assembly version match to avoid confusion, it’s not necessary. This is a good example of a case where they need to differ. I do suggest having the “Title” and “Description” note this fact to help avoid further confusion.

I want to thank Jiri for maintaining the Log4Net package and being responsive to the need out there! It’s much appreciated.

The State of NuGet

I’ve seen a few recent tweets asking about what’s going on with NuGet since I left Microsoft. The fact is that the NuGet team has been hard at work on the release and have been discussing it in various public forums. I think the feeling of “quiet” might be due to the lack of blogging, which I can easily correct right now!

In this post, I want to highlight a few things:

• What the NuGet team has been working on
• How you can track what we’re doing
• And how you can get involved in the discussion

Just to clarify, I have not left the NuGet project. Until my name is removed from this page, I will be involved. However, as I’ve been ramping up in my new job at GitHub (loving it!), I have been less involved as I would like simply because there’s only so much of me to go around. Once we get the project I’m working on at work shipped, I hope to divide my time a little better so that I don’t neglect NuGet. But at the same time, everyone else has stepped up so much that I don’t think they’ve missed me much.

The team and I are working through how to best keep me involved and we are starting to improve lines of communication.

NuGet Status Page

The NuGet team is currently working on NuGet 1.7, but in the meantime, we’ve shipped a status page at http://status.nuget.org/.

This state is design to provide the community with information about the overall state of NuGet as well as information about the future direction and plan of the NuGet team. Notifications about planned maintenance as well as outages will be posted in the “State of NuGet address” section and can be followed using the RSS feed. Additionally during these times the team with use this section to communicate any pertinent information.

NuGet is more than an add-in to Visual Studio. It’s an important service to multiple different clients and partners and we’re working on ways to improve that communication. The status page is a start, but we’re open to other ideas for improving communication.

NuGet Issue Tracker

As always, if you’re curious about the progress being made towards NuGet 1.7, just visit the issue tracker. The link I just provided shows a filtered view of issues that are still open for NuGet 1.7. You can select the Fixed or Closed status to see what issues have already been implemented for 1.7.

So even if our blogs get a little quite, the issue tracker is the source of truth about the activity.

NuGet JabbR

The NuGet team is moving more and more of our design discussions to our JabbR room. Don’t know what JabbR is? It’s a real-time chat site built on top of ASP.NET and SignalR with a lot of nice features. It’s similar to CampFire, but has great features such as tab expansions for user names as well as emojis! JabbR itself has a very active community surrounding it and they accept pull requests!

In fact, last night starting at around 11 PM we had a big design discussion around capability filtering. For example, if you are on a client that doesn’t support a feature of the package (such as PowerShell scripts), can we filter that out for you. If you have something to say about this, don’t respond here, go to the JabbR room!

What’s Next?

A big focus for us is getting the community more and more involved in NuGet. We hope the move towards leveraging JabbR more helps in that regard. We’re still hashing out some of the details in how we do this. For example, what should be discussed in JabbR vs our discussions site? I think JabbR is a great place to hash out a design and then perhaps summarize the results in a discussion item for posterity. What do you think?