NancyFX

The discussion, about what constitutes OSS and not, have been going on on Twitter and the .NET blogosphere for a couple of weeks now. The root of it all has been weather or not Microsoft should call their work with ASP.NET MVC as open-source ... [More] or not. Reading what has been said and taking part in the discussion myself I feel that quite often the discussion is clouded by our individual thoughts on what constitutes as open-source or not, rather then what the actual definition states. So what does the definition says? Well we can look at the Open-Source Definition, by the Open-Source Initiative, and the Free Software Definition, but the Free Software Foundation for guidance on that. I won’t recite any of sources because both have very clear definitions on their websites. What’s missing from this picture? There are a couple of things missing for both of them. Things like when and how often do you need to make source code publically available? Do you need to develop in the open, with public roadmaps and feature discussions? Do you have to accept code contributions or not? For the most of us (?) those are no brainers; you should put code out in the public as quickly as you can, engage in discussions with your community and accept contributions with open arms as long as it is true to your vision. However these are all values that we, as a community, layer on top of the definition of open-source and open-source software. These are things we have seen help increase the transparency in our projects, help improve quality and add more value to our work. You can take all of that away and still do open-source, but you are selling yourself short (if you ask “us”) if you do. What can we do? You tell me! One idea I had tonight, while arguing about this on Twitter, was that maybe we need a way to measure the maturity of open-source participation of a company/product. If you’ve ever read anything about REST you may have come across the Richardson's Maturity Model for services on the web. Basically it’s a measuring stick for how far you’ve come with your REST adoption. Check out the link so read about the 4 levels of the model. What if we could apply the same idea for open-source? What if we had something like this Level 3. Accepts patches Level 2. Make code available on a regular basis Level 1. Develops in the open Level 0. Compliant with the OSI / FSF definition of open-source These maturity levels aren’t something I’ve been philosophizing about for a long time, in fact they popped into my head about 30 minutes ago while I was engaged in the Twitter discussion. Just to be crystal clear; The number of levels and the the definition of each level is not something I would consider set in stone at the time of the writing. Instead I hope they can inspire to some interesting discussion and perhaps even a consensus on what such a model should look like. Maybe I’m just talking out of my ass here or maybe I am onto something. Either way, let me know in the comments. I personally thing something like this could help out when we, the community, talk about open-source and open-source software Permalink | Leave a comment  » [Less]

TL;DR A couple of days ago we (finally) managed to get v0.10.0 out of the door and it’s packed of goodies! Diagnostics, razor improvements, bug fixes, weighted request headers, model validation and lots of tweaks to existing features are ... [More] only a couple of things that went into this release. The community continue to bless us with their awesome work and this release had 22 authors totaling 250 commits, which is just jaw dropping! That puts us at 65 contributors to the Nancy source code. This release consisted of 23 updated (some new) Nugets and a total of 45 work items! For a complete list of things that’s part of this release (including breaking changes!), head over to check out the milestone at GitHub. So let’s have a closer look at some of the stuff in v0.10.0! Validating models just got easy Craig Wilson contributed some absolutely beautify code to help us get model validation into Nancy. Like all other features in Nancy, the validation stuff is shipped as a set of Nugets with the added ability of hooking in your own validation methods. In this release we ship Nugets to use either DataAnnotations or Fluent Validation to validate your models. Combining this with our model binder and you are definitely on the super-duper-happy-path! The contribution from Craig also contained the foundation to generate client-side validation based on your model rules, however this release does not contain the code to enable that but it’s definitely something we’ll be looking into in upcoming releases (maybe it will be your contribution that brings this to the community?!) The Nancy.Demo.Validation project, in the main solution, shows you how to use this feature and uses both DataAnnotations and Fluent Validation. Remember, it’s quite easy to plug in other validation frameworks too! Making sense of what the client sends you We gave the RequestHeaders class some love, by adding methods to access all available header names and values through properties. We also made the class implement IEnumerable<> to make it easier to work with the incoming headers. One of the biggest changes is the presence of weighted headers. The headers that can be weighted not returns IEnumerable<Tuple<string, decimal>>, instead of IEnumerable<string>, and will be sorted in descending order according to their weight. Not only will this enable you to manage weighted headers in a correct way, but it’s also an important piece of the puzzle for the planned content negotiation support, that we will ship in a later release. Sharpening the Razor The improvements, made to the Razor view engine, in this release really deserves a blog post of it’s own to make it justice. Despite that, I will give you a mile height overview of the changes and improvements that we’ve made. One of the things that we (me and Grumpydev) really wanted to sort out for this release was adding in Intellisense for our razor views and I am very happy to say that we’ve managed to do that. It includes a couple of custom build providers that is installed, into the bin folder of your project, with the razor Nuget and adds a couple of post-build events to make sure they stay there. I would lie if I said that getting the build providers to play ball was easy. It’s one of those dark corners of Razor customization that nobody speaks of and it involves quite a bit of Visual Studio magic. So to enable Intellisense, all you have to do is build your project, after installing the Nuget, and the Nancy.ViewEngines.Razor.BuildProviders.dll assembly will be copied into your bin folder. The Nuget will also wire them up for you in the web.config, moar super-duper-happy-path for you! While doing some refactoring work I also noticed how easy it would be to add support for .vbhtml files, so I did. This should be really handy to help you port that legacy MVC application over to Nancy ;) The included build providers contains one for these views so you should be able to enjoy Intellisese support if you ever find yourself in the need to use the Visual Basic views with Razor. Oh, speaking of dark corners of Razor, did you know that ASP.NET MVC installs a global handler for .cshtml and .vbhtml files? We didn’t. At least not until we got a bug report that Nancy wasn’t rendering views with the passed in model. Turns out that if you have a view, with the same name as one of the routes, the request would never be passed to Nancy. Instead the global handler would suck it in and render the view. How nice, right? WRONG! Well after speaking to the Razor team it turns out that you can disable this behavior with the, not so obvious, webPages:Enabled configuration key. We updated out Nuget to stick that into your config file when you install it. Craig Wilson didn’t only chip in with awesome model validation code, he also added support for @model and @ModelType directives, as well as making the Razor engine smart enough to automatically reference the models assembly or as Craig described it in this pull request The model's assembly is now referenced automatically regardless of whether an assembly reference exists in configuration. This makes the "it just works" statement a little more complete. In addition, if specified in configuration, the namespace of the model is automatically included in the razor file. That’s a very awesome little feature to have around! We also dropped our dependency on System.Web in the engine which means it will run in client profile. It also means that if you took for granted that it was around in your views then you are going to have to reference the assembly and namespace in the Razor configuration. We thing it’s a small price to pay to get rid of that dependency! All your Url are belong to us Two small, but oh so useful, changes where made to the Url type. You can now call ToString() and it will give you a correct string representation of the url. The second thing is that the type will now implicitly cast to an Uri instance, how awesome is that!? Not more White Screen of Death (WSOD) Have you ever noticed that if you tried to render a view, that Nancy couldn’t find, you would end up with a blank page? Yeah, not really useful is it? To our defense that we never our intention but we somehow forgot to make it more awesome. That is, until now. As of this release, you will now get a view that tells you that it was unable to locate the requested view and it will also tell you which file extensions, based on the available view engines, that can be used. Also expect a future release to also contain information about the locations that were inspected for the view. Doctor, what’s wrong with me?! Do you remember the first time we talked about adding in Diagnostics for Nancy? To be honest I can’t say for sure, but I know it was somewhere around v0.3/0.4 and that wasn’t exactly yesterday. It’s been a long time coming, but I am very pleased to tell you that we’ve included diagnostics in this release! It is important to be aware that this release only contains a couple of diagnostics tools, but we’ve put a lot of work into the diagnostics foundation and it will be really easy for us (that that “us” definitely includes you too! We want your contributions!) to add more diagnostics tool for each new release we make. The diagnostics contains both request tracing and interactive diagnostics. The interactive diagnostics is where things gets really interesting. It enables you to interactively (duh!) query Nancy, at runtime, to figure out what the heck is going in. Before you get too excited, this is not a query language like SQL where you can just fire of queries, even though it would probably be totally possible to implement (hmmm, any takers?). We are introducing the IDiagnosticsProvider interface and anything that implements this can hand our diagnostic capabilities. These are, quite literally, normal methods that are exposed on our diagnostics dashboard. It enables you to pass in primitive values and have rich result sets be returned and presented automatically. Anything that implements the interface will automatically be discovered and wired up on the dashboard. Not only that, but you can take full advantage of the, 1st class, dependency injection support of Nancy and take in what ever dependencies you want into your providers, making it super easy to do some pretty advanced stuff. Of course you are not restricted to only take dependencies on Nancy types, there is nothing stopping you from exposing a nice interface over your logs etc. The providers can, nicely, be dropped into a Nuget and reused across any Nancy project out there! Wanna know something really neat? The entire diagnostics dashboard is build using Nancy and backbone.js and is embedded into Nancy itself (woah! A Nancy application running inside of Nancy?! Yep!) It’s extremely fast and easy to use. So how do you get access to the diagnostics goodies? Glad you asked! All you have to do is to run in debug mode (although it’s possible to use it in release mode too, you just need to turn it on) and then browse /_Nancy/ in your application. It will give you some (very) easy instructions (really, it teaches you how to configure a password) to get started. We’ve only scratched the surface of this! Moar stuff! Really, I can’t list em all here so head over to the milestone at GitHub. So wuzz next? Well, first of all you won’t have to wait as long for the next release. We are going to try to get this out in about 3 weeks time and plan on focusing on trimming down the pull request queue and fix the reported bugs. We have no major features planned for the next release, but that does not mean that we’re not working on any. Quite the opposite, we are working on getting in support for async routes, content negotiation and proper caching support. We just don’t want to keep other stuff away from you while we work on these things and want to keep doing more frequent releases. Of course there is always the chance that we manage to finish one of them in time for the next release, or that someone contributes something really awesome that will be included! Thank you for making v0.10.0 possible!  Permalink | Leave a comment  » [Less]

Last night Ben Hall blogged about how he managed to get Nancy running on Heroku. It’s still an early experiment, and totally unsupported by Heroku itself, but it is very interesting to say the least. In essence this means that it might be ... [More] possible to run any Mono compliant (really guys, you need to pay attention to making this the case for your apps, it’s not much work at all) application on Heroku. Neat! - Nancy is a lightweight HTTP framework for building web services and sites. The framework runs on both the .net framework and Mono. Permalink | Leave a comment  » [Less]

Nancy is a lightweight HTTP framework for building web services and sites. The framework runs on both the .net framework and Mono. Out of the box, Nancy supports GET, POST, PUT, PATCH, DELETE, OPTIONS and HEAD (although these are a special ... [More] case of GET requests and handled differently by the framework) requests. These are the subset of the RFC-2116 that we’ve found useful to support in Nancy. We do understand that your application might have the need to handler different kinds of requests and there are ways around this. It’s not something we’ve specifically built Nancy to support, but because of the design we use, you can add additional handlers for other types of requests with very little effort. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 public abstract class CustomRequestVerbsModule : NancyModule{    protected CustomRequestVerbsModule()    {    }    protected CustomRequestVerbsModule(string modulePath): base(modulePath)    {    }    public RouteBuilder Trace    {        get { return new RouteBuilder("TRACE", this); }    }} In the above code I created a custom Nancy module that added a method with the name of the request verb that we want to add support for. The return type of the method is a RouteBuilder, a helper class that is used to provide the syntax Nancy uses for defining route handlers. Once the module is created, all you have to do to start handling requests of the new method is to inherit your modules from the new base class and add your handlers. That’s all there is to adding support for additional request methods in Nancy! Permalink | Leave a comment  » [Less]

”To sum up, I would just kindly advice Andreas to invest his time and enthusiasm into something better, cause this Nancy was definitely born dead." 368 days ago I first announced Nancy on Elegant Code and that was a piece of advice that I ... [More] received among the many comments that followed. You know what? Back them he might have been right. Nancy was a personal project that I spiked out in a couple of nights and let loose into the wild with no real expectations. However, taking a step back an looking at the year that has passed, the complete opposite has unfolded . Since the first commit was made by me, on the 20th of November 2010, quite a lot have changed for Nancy. More than I could have possibly have imagined to be honest. They grow up so fast In the announcement post I wrapped up with a list of things I knew I wanted to get into Nancy at that time. Some of them were pretty big tasks, some quite small. A much richer request object The ability to inject dependencies into Nancy modules Conditions on actions View engine integration Ship with a nice bunch of response formatters Self-composed framework Request and Response interception NuGet presence Command line (powershell?) support for spawning up a Nancy application project Provide self-hosting somehow Not only did we complete all of the above, but those are just the tip of the ice berg of things that’s happened during the last year. Today Nancy’s matured into an awesome framework for building web sites and services on both .net and Mono. The list of features that are now supported is too long to list here, but a couple of highlights are support for all the major view engines, inversion of control containers, authentication, request pipelines (both on application and module level), model binding and so much more stuff that it blows my mind. One thing that pleases me though, is that even with all the added features, Nancy is still a light weight framework because of the way it’s architecture. It’s built with a small core that has some nice extension points built into it. Extensions are built in the form of Nugets and to add a feature you simple grab the Nuget for it and of you go. Right now we have 20 official nugets and a couple of ones that’s been created by the community Standing on a thousand shoulders This is not the result of the labor of a single individual, quite the opposite. Nancy a result of the amazing community that’s evolved around it and the incredible list of 57 people that have contributed over 100 pull requests and of course everybody that’s ever provided feedback, suggestion and that’s blogged, created screencast or talked about Nancy at a conference or other gatherings. The project is a regular on the GitHub Languages page under the C# page, with 504 watchers and 132 forks at the time when I write this post. If you include the number of people that’s taken part in discussions on our user group and on Twitter. Thank you so much! A grumpy fella from the UK Early one on guy from the UK took Nancy at heart and started contributing some pretty impressive stuff to the project. Right from the start he “got Nancy” and understood the vision I had for the project. It didn’t take long (too long if you ask him) before it was only fair to add him as a core developer and get his name on the mailbox. I am of course talking about Steven Robbins, a.k.a @grumpydev. Not only has he put a lot of awesome stuff into the project, but he’s also become a good friend over the year that’s passed. Thanks for all your work on Nancy buddy! Are we there yet? Not by a long shot! We’ve got so much stuff planned for the project and there are so many suggestions and contributions coming in every week. However it is important that we pace out self and make sure things does not grown in an uncontrolled rate or direction. Every thing that is added into Nancy is still measured on the same scale as before. Controlled chaos as it’s best! So here’s hoping for another awesome year!   Permalink | Leave a comment  » [Less]

A quick heads up. In Nancy 0.6.0 we introduced a change that made the application scan, for all available views, and cache them upfront. While this is good for performance, because it reduces view loading time and limits I/O operations, it does ... [More] pose a slight nuance then you are creating you view. Because of the cache, each time you made changes to the view template you had to restart the webserver so that the Nancy startup code ran again. A bit of a pain in the sitting area, I agree. This update is not in the 0.6.0 release it self, not in the NuGet packages. So in order to get a hold of a copy that uses this you will have to either download the latest source code and built it yourself, or grab the latest artifacts from our TeamCity server.    Permalink | Leave a comment  » [Less]

Nancy recently reached version 0.6.0 and was the result of 220 changed files, divided into 126 commits by a total of 12 different authors. That alone is pretty damn awesome if you ask me, but of course we didn’t just make random changes to ... [More] the code, we did try to add some new cool stuff as well! The major parts that got some attention in this release were performance, there bootstrapper, the view engines and lots of internal changes that you will only notice if you work with the code. So let’s dig in an see what we we’ve concocted Bootstrapper We are quite proud of the bootstrapping approach we have taken in Nancy. It’s right in the center of everything and helps us implement new functionality with minimal effort but it also helps Nancy users get dependencies into their modules absolutely minimal effort. In the 0.6.0 release we put quite a lot of effort into the bootstrapper code. Un essence it can be summed up with: A lot cleaner public facing API Makes it easier to implement a custom boostrapper for a different container Reduces friction when adding Nancy functionality moving forwards View conventions Prior to 0.6.0 you were pretty limited to where Nancy would look to resolve views to render. In fact you were limited to a folder called views, that had to be in the root of your application. Well that’s now changed into being convention driven instead, with the possibility to modify the conventions yourself. The default conventions that is shipped with Nancy are 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 private static void ConfigureViewLocationConventions(NancyConventions conventions){ conventions.ViewLocationConventions = new List<Func<string, object, ViewLocationContext, string>> { (viewName, model, viewLocationContext) => { return string.Concat("/", viewName); }, (viewName, model, viewLocationContext) => { return string.Concat("/views/", viewName); }, (viewName, model, viewLocationContext) => { return string.Concat("/views", viewLocationContext.ModulePath, "/", viewName); } };} Providing your own is equally as simple. You create a custom boostrapper (that Nancy will find automatically and use) and modify the list (yes, conventions are stored in an IList<Func<string, dynamic, NancyContext>> instance) in what ever way it please you 1 2 3 4 5 6 7 8 9 10 public class CustomBootstrapper : DefaultNancyBootstrapper{    protected override void InitialiseInternal(TinyIoC.TinyIoCContainer container)    {        this.Conventions.ViewLocationConventions.Add((viewName, model, context) =>        {            return string.Concat("/custom/", viewName);        });    }} View caching Let’s be blunt. View engine were slow in Nancy before we pushed out 0.6.0. Why? Well, for different reasons for different engines, but it all boils down to the fact that views were located and compiled on each and every request. Ya, I know.. slow. But no more! The first thing we did was to have Nancy identify all views that could be rendered (based on the available view engines in your application) and cache them at application startup. This means the file system (or what ever means of storing your views you use) only gets hit once, removing an expensive traversal from the request/response cycle. The second thing we implemented was a cross-engine view cache. This means that we now cache the compiled, but not initialized, version of a view. Not having to compile the view on each request was huge performance boost. How big you ask? I’ll let you view it with your own eyes. I know! Pretty impressive, isn’t it. Let me give you some help to understand what you are seeing. The (M) means master branch and (E) means experimental branch. While we were working on this we used a different branch so these benchmarks were taken right before we merged experimental back into master. There’s some fantastic performance improvements across the board, but the one I would like to highlight is the one for string. This means a route that just returns a simple string. Technically this is not a view, but we used it as a reference point because it’s the simplest form of response. A 28% increase in performance is pure optimization in the request/response life cycle and even then it all came down to some small, clever, changes. What? You mean the green bar? Oh! That green bar. Well, turn’s out that hitting csc.exe on each request can really kill performance really horrible. All in all, we are very happy with the changes we made here. Razor As if the massive performance boost wasn’t enough we managed to squeeze in some very anticipated features. The two big ones are support for partial views and layouts. We managed to decipher the crypto that is layout support in the razor parser (poor Steve used reflector more than anyone should have to do in a single stretch) so the implementation we provide should be wired up like it is in ASP.NET MVC. There are also some other changes that we have documented on our wiki. Super-simple view engine The big changes here are added support for partial views and layouts. This little engine is starting to become quite rich on features but it is still extremely small and embedded into the Nancy dll, so it is accessible when ever you are working on a Nancy application. Dotliquid We added a new view engine, this time for the dotliquid markup syntax. And Bob’s your uncle! That’s it! It’s not all of it, but that’s the essence of it. We did fix bugs, improve code quality, create more NuGet packages and a lot of small changes as well. So, if you haven’t already, go check it out at nancyfx.org or at the official NuGet feed. Until next time, happy coding! Permalink | Leave a comment  » [Less]

Little more than a week ago, I sat down to add the possibility of using anonymous types as models for views in Nancy. Now, since not all view engines can handle anonymous types as their model I decided I would intercept them, along the way to ... [More] the view engine, and convert them into an ExpandObject instead. In order to do this I needed to detect them first, and after poking around the reflection API, and use Google + Twitter to confirm it, I came to the conclusion that there is nothing in there that will tell me if the instance I have is of an anonymous type or not. Then I got a tweet from Joseph Gray, also known at @MrJosephGray on Twitter, sent me a link to a blog post by Jef Claes titled Checking for anonymous types and it contained just what I needed. It works beautifully, until I ran my code on Mono that is. Even though the blog post is not clear on it, I was aware of that the detection method relies on undocumented naming conventions and no guarantee that any of the traits, that it checks, won’t be changed in the future by Microsoft. That is also why I was not surprised that there were issues while running it on Mono. After taking the debugger out for a quick spin it was evident that it was the type name that was the culprit. On Mono (at least on 2.10 that I am running), the name of the generated type contains AnonType and not AnonymousType and it was a trivial task to patch the extension method to check for that as well. The full implementation that I am using in Nancy is listed below 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 using System;using System.Reflection;using System.Runtime.CompilerServices;/// <summary>/// Contains miscellaneous extension methods. /// </summary>public static class Extensions{    /// <summary>    /// Checks if the evaluated instance is an anonymous     /// </summary>    /// <param name="source">The object instance to check.</param>    /// <returns><see langword="true"/> if the object is an anonymous type; otherwise <see langword="false"/>.</returns>    public static bool IsAnonymousType(this object source)    {        if (source == null)        {            return false;        }        var type = source.GetType();        return type.IsGenericType                && (type.Attributes & TypeAttributes.NotPublic) == TypeAttributes.NotPublic               && (type.Name.StartsWith("<>", StringComparison.OrdinalIgnoreCase) || type.Name.StartsWith("VB$", StringComparison.OrdinalIgnoreCase))               && (type.Name.Contains("AnonymousType") || type.Name.Contains("AnonType"))               && Attribute.IsDefined(type, typeof (CompilerGeneratedAttribute), false);    }} Permalink | Leave a comment  » [Less]

A week ago I was invited to participate in he Hanselminutes postcast by Scott Hanselman to talk about Nancy and Micro Web Framework. The recording for episode #270 can be found at Nancy, Sinatra and the Explosion of .NET Micro Web Frameworks ... [More] with Andreas Håkansson I had a great time talking to Scott, who is an excellent host, but one thing I did not get an opportunity to do was to extend my gratitude to the awesome people that are forming up a community around the project, everybody from the people that blog, tweet, screencast or in some other way help Nancy grow into an awesome framework – so thank you to all of you! The following people have all contributed to the Nancy repository and have helped us get many of the awesome features and bug fixes (if your name should be on this list, but it not, please drop me a line and I will get sorted out!) Andy Pike, Bjarte Djuvik Næss, Chris Nicola, David Hong, Graeme Foster, Guido Tapia, Hernan Garcia, Ian Davis, Jonas Cannehag, José F. Romaniello, Karl Seguin, Luke Smith, James Eggers, Jason Mead, Jeremy Skinner, João Bragança, Johan Danforth, John Downey, Maciej Kowalewski, Martijn Laarman, Mindaugas Mozûras, Patrik Hägne, Pedro Felix, Piotr Wlodek, Phil Haack, Robert Greyling, Simon Skov Boisen, Steven Robbins, Thomas Pedersen, Troels Thomsen, Vidar L. Sømme I would like to extend a special thank you and shout out to my friend and co-conspirator Steven Robbins a.k.a @GrumpyDev on Twitter. He is a continuous source of awesome for Nancy and the project is better for having him onboard, that is one thing I am certain on. Thank you buddy! Permalink | Leave a comment  » [Less]

It seem that every 3-5 month or so, the discussion on the state of the .NET open-source community flairs up. Some say it’s a dead horse being beaten, other that it’s a vibrant, thriving community. Sound familiar? Who cares?! Seriously, who ... [More] cares? The right thing to do in either case is the exact same thing; keep injecting more value into it! If the movement (if you can call it that) is truly dead, then what? Do we just roll over and play dead, or do we add more value to it and help breath new life in to it? If your answer is the former then you are simply not an open-source kind of guy. Now imagine that it’s is, in fact, a vibrant and thriving community, full of goodies to choose from. What should be do then? Stop adding value to it since it’s already doing well, or do we keep on pushing to add even more value into it? We keep adding value, of course, if it wasn’t already obvious that would be my answer. Alright then, how do we inject move value into it? Contribute to an already active project or start a new one? It truly depends on your visions. First of all let me make it perfectly clear that I think diversity is not only a good thing, but a sign of a healthy community. There is no single “silver bullet” that will solve all problems or in a way that out domain requires them to. It’s very rare for a “all-in-one” solution is the best for your scenario and that’s why I believe opinionated solutions is required. Everybody won’t agree to a single opinion, it’s just not ever going to happen, so how could a single framework or product be the solution to all problems we face in our industry? It can’t. The first thing you should get out of your head is that your source code is where the gravy is. Sticking to that story won’t get your very fare. Any decent programmer can probably reproduce any functionality with their own implementation. It might not be as fancy as your solution, but I’ll bet you that it would work well enough to solve the problem they were facing – they’d see to that. So if the value is not in the source code, that you’ve spent weeks, maybe months, perfecting and to work just the way you wanted it to, with all the fancy solutions and patterns in place, then were is it? It’s in the vision of the source code. The vision is the heart and soul of your project and it’s what will ensure that the project can live on even if you loose interest. It’s your opinions on how things should be done. Now, of course, if you vision is nearly the same as the next guy and all you do is pinch his source code and call it your own thing, then you’re just being an ass hole. I’m sorry, but you are. If you have a clear idea on how you thing a certain set of problems should be solved, that’s when you have the foundation for a nice opinionated solution…that’s the vision of your project. The vision of the project should be set in stone before you make the first public release. Be careful to be blinded by the massive amount of suggestions and contributions that you might be getting. If they will lead you down a path that is not true to your vision – ignore them. Send them a “thank you, but this is not for this project” and if they don’t like that then they should distil their visions into their own project. It’s impossible to say which would be the better solution – heck, why can’t both be just as good but suite different people? Diversity. If you nurture the vision of your project well enough and attract equal minded people then you have started a community and they will make sure the project stays true to the original vision, trust me. Should you suddenly loose interest in the project, or for some other reason not be able to commit to the cause anymore, the community can simply fork and create a new authorities branch. This has happened time and time again in many of the big open-source projects. I’m happy to say that I keep seeing the diversity in the .NET open-source community grow as we speak. I keep seeing more and more small, opinionated, projects pop up and that they are being embraced by a subset of our community as a whole. Sure, the .NET community has probably quite a bit more to invest in open-source, but it’s getting there and the only way to get there faster is to be part of the ride!  Permalink | Leave a comment  » [Less]