Recently, I pushed the official second release (v0.2.0) of omniauth-wsfed to omniauth-wsfed is a WS-Federation and WS-Trust strategy for OmniAuth enabling integration with Windows Azure Active Directory (formerly Access Control Service), Active Directory Federation Services (ADFS), custom Identity Providers built with Windows Identity Foundation (WIF) or any other Identity Provider supporting the WS-Federation protocol. Specifically, the 0.2.0 release contains several enhancements related to SAML token validation and WS-Trust + WS-* field validation as well as an overall cleaner and more thoroughly-tested codebase (see the release notes or Github repo for complete details).


Almost four weeks after the release, reported just over 600 downloads (all time, for all versions) and 124 downloads for the new version. Well… Not bad I guess, but definitely not the type of numbers that get your gem recognized on Ruby Toolbox. Reading between the numbers however, there are a couple of positives – a) At the time of this post there were 124 downloads of the new version and only a couple of those were from my current project; b) there are definitely other developers using it! Only a couple of those downloads were related to my current project as I’m in the middle of a refactor effort to organize all enterprise AuthN logic into a Rails engine shared by all applications. Once the engine is finished, the download count should increase quite a bit as it gets promoted through our test environments and onto all of the developer installations. Overall, it’s not a bad start since single sign-on and identity federation for enterprise applications are problems more commonly solved by large corporate codebases written in Java or C#. Most times, Ruby projects are solving this problem with OAuth and using well-established social Identity Providers such as Google, Facebook, Twitter, etc.

Building Some Street Cred…

So why all the information for a Ruby gem targeting such a narrow problem space? Well for starters, omniauth-wsfed finally reached a state where I felt comfortable openly promoting it instead of just using it on internal client projects. I had been thinking about promoting it for a while, but felt the library needed just a little more polish. Additionally, I read a recent post on you’ve been Haacked that finally gave me the motivation to write this post. In the post, Phil Haack discussed his opinions about establishing trust for open source packages on NuGet. Haack discussed several possible options including package signing and using custom NuGet identity verification; but arrived at the conclusion that you’re going to get the most for your effort by simple, established techniques such as social identity verification, download counts and grass roots promotions like the one you’re reading now… :-)


The interesting part about the article was that it doesn’t just apply to NuGet open source packages targeting the .NET Framework. It applies to open source packages in general – whatever the language. Bottom Line: if you’ve written something that you think would be useful to others, promote it; talk about it; encourage others to contribute.

Trust Me… I Have Badges

Aside from the suggestions in Haack’s post, there are some great options for Ruby projects (either completely free or free for open source projects) that can help establish additional credibility for your project. Each of these services come with their own “badges” for display in your Github README calling attention to the fact that you and your contributors are committed to quality. If you haven’t noticed, these are starting to pop up on more and more popular Ruby Github projects. Now that there’s an omniauth-wsfed release I’m proud enough to promote, I got curious about these services and went investigating…


I’ve added these services…

  •   Code Climate – a code quality service for Ruby repositories that tracks metrics such as duplication, code churn and method complexity. Code Climate requires absolutely no effort other than pointing it to your Github repo. 
  • – a cloud-based, continuous integration environment for open source projects supporting many languages including C, C++, Java, Perl, PHP, Python, Ruby, etc. Travis-CI is incredibly easy to setup and requires only a Github account link and a YAML configuration file. Specifically for Ruby projects, Travis-CI is capable of continuous integration against ALL popular Ruby implementations – an insanely useful feature because you can validate your code under conditions and  in platforms that you might otherwise never use.
  •   Version Badge – as long as you’ve released a gem on, Version Badge will provide a badge indicating the most recent version number.

I’m considering these services…

  • Gemnasium – a service that evaluates your project in terms of its dependencies. Projects are scored on whether or not their dependencies are up-to-date and the service notifies you if any new dependencies are available to test with.
  • Coveralls – a code coverage service for Ruby and Python projects that integrates with Travis-CI.

I Want to Hear from You!

One final thing I wanted to call out is the importance of full disclosure in open source projects. It’s extremely important to disclose any known issues (whatever the severity) as well as the project roadmap to potential users of your software. Awareness for known issues before being discovered accidentaly by your consumers will reduce the overall friction of adding your OSS project as a dependency. Personally, I feel much better about acquiring a dependency on a project even if it has some issues as long as I’m aware of them (and how they might affect me) and know the author(s) are actively working on a resolution. Github Issues are a great way to track these details. You can checkout omniauth-wsfed’s issues / roadmap here.