How Google broke the OSS compact with Angular 2.0

When I first wrote the title, I had to pause for a moment to consider if I was actually writing this post or if it was a bad dream. As it turns out, at least from my vantage point, what I’ve seen thus far, which candidly isn’t that much, has been much like a bad dream. For purposes of this post, what matters more is what we know we haven’t seen. Nonetheless, I have seen enough to make a few conclusions I’ll express here.

It’s helpful to start with some defined terms and a framework that I can use as a backdrop to support my argument. In this case, I’m relying on the classic OSS development model described by Eric Raymond in his 1997 essay The Cathedral and the Bazaar. I won’t go into all of the model’s facets save one: That all users should be treated as co-developers. The over-arching theme of OSS is one of transparency and at least get as close as possible, to true democratization.

In reality though,democratization is often preached by the same people that just as often don’t practice it. I won’t delve into motive or intent. Rather, I’ll simply rely on what I’ve seen and observed as an outsider looking at the building that has its curtains drawn – trying to get a glimpse of what is going on inside. Is it my or any of our business? You bet it is as collectively, we are part of a large community that is responsible for Angular’s success. We are impacted by decisions being made in the dark.

Looking at Angular 1.x, it has quickly become one of, if not the most popular MV* web development frameworks today. There is a robust community and at last count, has over 1000 contributors. All one has to do is navigate to to see how robust and vibrant the community is.By all accounts, the Angular Team appreciates this community through the comments expressed at the 2014 ng-Europe Conference. In this day and age, words don’t mean nearly as much as actions. I’m a member of that ever-growing legion of people that judges by what is done, not what is said.

There is no doubt the external community (those outside Google) is the reason why Angular has been so successful. It’s common sense after all. Without broad uptake and support, an OSS Project may be many things, but a success won’t be one of them, unless of course, the goal was for the software to only be used by a few people.

Today, the world is abuzz with mentions of Angular 2.0. Here and there are mentions and perhaps the briefest of glimpses of what 2.0 will be. We keep hearing that it’s not an upgrade, but a complete rewrite, that it is for modern browsers, support for ECMA 6, etc. We’ve heard they seek to make 2.0 more modular and to correct things that weren’t right in 1.x. It all sounds good. But my question is simply this “Where is it? Perhaps you are part of an enterprise that adopted Angular and are wondering what the future will hold. What will happen with 1.x support? Should you plan for an upgrade? Can you upgrade? What about the supposed lack of support for certain browsers? Can you test and verify that? What are the plans after the first release? Again, where are the bits? This is one of the first blog posts on the matter: Note the date – March, 2014. You’ll soon see how common that date is.

As it turns out, there were some resources where we could start to get a picture. The problem is, that momentum never carried though. One such site is the learn Angular site: Note the date: March, 2014. This is nearly an 8 month old post. Supposedly, the design documents are kept on a Google Drive: There was much hype about the designs being released: Note the date – March 2014. After that, there has been for the most part, radio silence until the ng-Europe conference. But even at the conference, there still wasn’t much in the way of meaningful details. Looking at the documents today, they are either out of date or completely unreadable. Many have been crossed-out entirely. What does this mean? Has that design been scrapped? Is it a bad edit? If there is meaningful information in either the doc library or the source repos, then it is like finding a needle in a haystack. If the goal was to achieve secrecy through obfuscation, then congratulations – mission accomplished. It would be fair for some to conclude that Angular 2.0 is mere vaporware. I’m not willing to go quite that far.

Here’s my contention: if all of this was around the first release of Angular, fine. We had nothing in the first place and the team is trying to get things squared away before going public. I’ll say this, had this been Angular’s first release, where there was mis-communication and partial transparency, the prospects of success would not be there. The fact is, this IS NOT Angular’s first release. Clearly, 2.0 is a revolutionary step over 1.x. The Angular Team looking to capitalize and build upon Angular 1.x’s success. As such, the community that was praised at ng-Europe has a reasonable expectation to be kept in the loop. That’s the way you’re supposed to treat the community that makes up your development partner base. To me, it seems rather common-sensical. Why on Earth would a team want to disenfranchise the very community it relies upon and praises? Is it meaningful praise or does it just make for good copy? Words are cheap and easy. Again, it’s what you do that counts.

There’s an old saying in business and politics: You dance with the one that brought you…

If some other notable companies engaged in this sort of behavior, they would be publicly flogged. I’ll leave it to the reader to speculate on who those notable companies are.

My request of the Google Angular Team is a simple one – stop with the secrecy. Get the community involved. I’m not saying there has to be design by committee. That’s never a requirement in OSS. There should however, be an opportunity for the public to review and comment. Whether you implement that feedback is up to you. The public has a good way of showing its support or lack thereof. There are many individuals and organizations that not only need time to evaluate, they are owed that time. That is part of the compact. That’s how you earn and retain trust.

The public has put its collective trust in Angular. The Angular Team should return in kind.

Posted in OSS | 28 Comments

Chocolatey Now has Package Moderation

Well just after three years of having, we’ve finally implemented package moderation. It’s actually quite a huge step forward. This means that when packages are submitted, they will be reviewed and signed off by a moderator before they are allowed to show up and be used by the general public.

What This Means for You Package Consumers

  • Higher quality packages – we are working to ensure by the time a package is live, moderators have given feedback to maintainers and fixes have been added.
  • More appropriate packages – packages that are not really relevant to Chocolatey’s community feed will not be approved.
  • More trust – packages are now reviewed for safety and completeness by a small set of trusted moderators before they are live.
  • Reviewing existing packages – All pre-existing packages will be reviewed and duplicates will be phased out.
  • Not Reviewed Warning – Packages that are pre-existing that have not been reviewed will have a warning on Since this is considered temporary while we are working through moderation of older packages, we didn’t see a need to add a switch to existing choco.

Existing packages that have not been moderated yet will have a warning posted on the package page that looks like

This package was submitted prior to moderation and has not been approved. While it is likely safe for you, there is more risk involved.

Packages that have been moderated will have a nice message on the package page that looks like

This package was approved by moderator mwrock on 10/26/2014.

If the package is rejected, the maintainer will see a message, but no one else will see or be able to install the package.

You should also keep the following in mind:

  • We are not going to moderate prerelease versions of a package as they are not on the stable feed.
  • We are likely only moderating the current version of a package. If you feel older versions should be reviewed, please let us know through contact site admins on the package page.
  • Chocolatey is not going to give you any indication of whether a package is approved or not. We expect this to be temporary while we review all existing packages, so we didn’t see much benefit to the amount of work involved to bring it to the choco client in its current implementation.

What This Means for Package Maintainers

  • Guidelines – Please make sure you are following packages guidelines outlined at – this is how moderators will evaluate packages
  • Re-push same version – While a package is under review you can continually push up that same version with fixes
  • Email – Expect email communication for moderation – if your email is out of date or you never receive email from chocolatey, ensure it is not going to the spam folder. We will give up to two weeks before we reject a package  for non-responsive maintainers. It’s likely we will then review every version of that package as well.
  • Learning about new features – during moderation you may learn about new things you haven’t known before.
  • Pre-existing – We are going to be very generous for pre-existing packages. We will start communicating things that will need to be corrected the first time we accept a package, the second update will need to have those items corrected.
  • Push gives no indication of moderation – Choco vCurrent gives no indication that a package went under review. We are going to put out a point release with that message and a couple of small fixes.

Moderation Means a Long Term Future

We are making investments into the long term viability of Chocolatey. These improvements we are making are showing you that your support of the Chocolatey Kickstarter and the future of Chocolatey is a real thing. If you haven’t heard about the kickstarter yet, take a look at

Posted in chocolatey | Tagged | 20 Comments

Chocolatey Kickstarter–Help Me Take Chocolatey to the Next Level

I’m really excited to tell you about The Chocolatey Experience! We are taking Chocolatey to the next level and ensuring the longevity of the platform. But we can’t get there without your help! Please help me support Chocolatey and all of the improvements we need to make!

The Chocolatey Experience

Posted in chocolatey, Uncategorized | Tagged , | Leave a comment

Hypermedia hangout: Collection+JSON, HAL, and building .NET hypermedia APIs with Nancy and ASP.NET

Yes that title is a mouthful. Recently I had the pleasure of doing a google hangout with Jonathan Channon of Nancy fame and Phil Cleveland on a topic you’ve heard me be slightly passionate about, Hypermedia.

You can find the full hangout which was published on air here, which was recorded for your enjoyment and displeasure :-)

My reasoning for getting in the convo was a bit selfish. I maintain a library for Collection+JSON APIs (which I’ve never blogged about) which I want to be used with Nancy.

Originally the library was built strictly for ASP.NET Web API, however after getting feedback from Andreas, that I should decouple it so NancyFx users could use it. I took his advice and did that! I refactored into 3 packages two of which can easily be used in Nancy. However, no one is doing it. My hopeful result for this call with Jonathan is that would change as he is deep into Nancy and interested in Hypermedia. It looks like I reached that goal :-)

In the hangout we start off (well mostly I was talking) talking about Hypermedia itself and different formats, namely HAL and Collection+JSON. Then we went into looking at a few sample APIs (including out issue tracker example from the book) using Collection+JSON, my CJ library, as well as how to implement a hypermedia API / useful patterns. Along the way we also delved into Profiles and the role they play for hypermedia APIs. Finally we ended the discussion talking about what this means for Nancy and what we could do to enable CJ in Nancy. That led to the creation of this github project! Jonathan and I will be iterating the next few weeks on bringing CJ to a Nancy near you.

Let the hypermedia games begin!

Posted in collectionjson, HTTP, Hypermedia | 1 Comment

Solving Json discrepancies using a JsonConverter

During my day job I am a client developer who is beholden to various back end API’s. Normally these API’s are well thought out and pretty easy to use, and normally their resulting json model make sense. But as we know, normally does not mean always. A few weeks ago I was implementing a feature which and built a object model based on the response from the API and the needs of my feature. Fast forward to present time and I am implementing another feature, similar but different. At first glace of the resulting json coming from the API it dawned on me that I could resume my object model from before (this makes sense since the features are in the same scope and are very tightly coupled).

As I set out to code my solution I hit a point where I needed to desearlize my json document to my object graph. No big deal as I am using and this is cake. But we know that nothing in software is cake. I immediately get an error while deserializing my graph, but why.

Below is my original json graph

"participants": [
  "id": "1ab644ce-481d-443f-a569-202a06cad740",      
  "calls": {
      "id": "c72537f6-af1e-4afe-abc2-5815b25960eb"

This graph looks pretty normal (note that most properties were removed as they were just noise). I have an array of participants and each participant has a calls subobject.

No look at the json graph from the 2nd api hit

"participants": [
  "id": "1ab644ce-481d-443f-a569-202a06cad740",      
  "calls": [
      "id": "c72537f6-af1e-4afe-abc2-5815b25960eb"

Do you see the subtle difference? In the second graph the Calls subobject is not an object but rather an array of objects. WTF????

I stared at this problem for some time trying to find the most elegant way to solve the problem and be able to resume my object graph, since the graph is expected to be the same.

The solution I found was to use a JsonConverter which will allow me to custom convert my Calls node as needed.

The first thing I needed to do is decorate my Call property in my object graph as below

        public VoiceConversationCall Call { get; set; }

The next thing I need to do is create my VoiceConversationCallsConverter. Inside this converter I am going to determine if the node currently being parsed is an object or an array and return back the correct value.

    public class VoiceConversationCallsConverter : JsonConverter 
        public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
            if (reader.TokenType == JsonToken.StartObject)
                return serializer.Deserialize(reader);
            if (reader.TokenType == JsonToken.StartArray)
                var asArray = serializer.Deserialize<List>(reader);
                if (asArray != null && asArray.Any())
                    return asArray.First();

                return new VoiceConversationCall();

            return serializer.Deserialize(reader);

        public override void WriteJson(JsonWriter writer, object value, JsonSerializer serializer)
            serializer.Serialize(writer, value);

        public override bool CanConvert(Type objectType)
            return true;

Pay attention to the ReadJson method. Inside this method I am looking at the TokenType for the current node and asking if it is an object or an array. once I know the TokenType I can deserialize my reader into the correct type and return it as needed.

Doing this allowed me to have a single object graph (again, which is expected) and process two slightly different json graphs.

Till next time,

Posted in C# | Tagged | Leave a comment