-
Our Open Source policy at eVision
There is a problem within our industry, particularly around .NET, known as the "no-contrib culture". That is, companies take and benefit from OSS but don't given anything back and also prevent their employees from doing so. A while ago I blogged about establishing an Open Source Software policy at a proprietary software company that happens to consume and depend on a significant amount of open source libraries. eVision was a typical company in that the standard employment contract had that catch-all clause that they own everything one does on a computer.
With the proliferation of OSS, the fact the platform we predominately build on is going OSS, and the fact that OSS is a viable business strategy (even within proprietary businesses), this was a somewhat short-sighted. Indeed, several employees were simply ignoring this; a situation which was in neither party's interest.
-
Establishing OSS policies in a proprietary software company
My company produces proprietary software but consumes a lot of FOSS libraries and components. Until recently, our standard contracts were of the 'we own everything you do' type. Obviously that created some difficulties for someone like myself given that I'm active in the .NET OSS community. The irony being that if I signed it, I wouldn't be able to support the very OSS libraries I maintain and that the company uses.
We'd like to establish a corporate policy where developers can contribute back and, possibly, create new OSS. I believe this is strategically a good move for several reasons, including:
-
Gulliver's Travels Tests
Like writing lots and lots of fine-grained "unit" tests, mocking out every teeny-weeny interaction between every single object?
This is your application:

Now try to change something.
-
Bubbling exceptions in Nancy up the owin pipeline
In the application I am building I have a requirement to do common exception handling within my OWIN pipeline via custom middleware:
private class CustomExceptionMiddleware : OwinMiddleware { public CustomExceptionMiddleware(OwinMiddleware next) : base(next) {} public override async Task Invoke(IOwinContext context) { try { await Next.Invoke(context); } catch(Exception ex) { // Custom stuff here } } } -
Protecting a Self-Hosted Nancy API with Microsoft.Owin.Security.ActiveDirectory
This post is the Nancy version of Vittorio's "Protecting a Self-Hosted API with Microsoft.Owin.Security.ActiveDirectory". Since I'm lazy, I may even be lifting some parts of it verbatim, if you don't mind, Vittorrio ;)
I'm going to skip the intro to Owin etc, if you are reading this, you probably know all about it by now. (Except for you Phillip; Get yout s**t together man!). This tutorial will be using Nancy.MSOwinSecurity that I introduced in the previous post.
What I am going to show you is how you can set up a super simple Nancy HTTP API in a console app and how you can easily secure it with Windows Azure AD with the exact same code you use when programming against IIS Express/full IIS.