The pragmatic .NET developer
Long-time friend, fellow co-host of the GSDF and the coding genius behind the open-source Ogre3D engine Steve Streeting has written an interesting piece on Open source adoption; countering the fear and doubt. I have no doubt that this was fueled by a lengthy discussion last night in the Ship & Crown pub – a common ritual after our GSDF meetings.
The reasons why I adopted .NET as my primary platform despite being tied to a single-supplier are:
- Ease of deployment & set-up
- Low resistance to adoption
- Great tool integration
- Official & community support
- Love for C# and the CLR
The ALT.NET movement
Many .NET developers are reluctant to look wider afield but this is not exclusively the case and a person focused on the .NET platform but open to selecting beneficial alternatives to the Microsoft prescription is exactly what the ALT.NET moniker was coined to encapsulate.
SourceForge lists over 6,000 open-source C# projects alone and many well-known open source Java & PHP projects have made their way to the .NET platform. NHibernate, NUnit, NCover, Spring.NET & DotNetNuke alongside new .NET developments such as xUnit.NET, SubSonic, Subtext etc.
Best of breed
Where a non-Microsoft option is functionally superior or more cost effective I will consider it whether it is proprietary or open source.
I do not however select a solution simply because it is considered the “best of breed” at that particular moment. Integration, training, availability of support and experienced developers, deployment, cost, barriers to entry and roadmaps must be taken into account.
Given that Microsoft provide the .NET platform anything ‘in-the-box’ scores highly in many of these areas.
Sometimes a non-Microsoft solution comes out on top or there is a compelling reason to adopt it anyway. This is why my toolkit already contains Subversion, TortoiseSVN, AnkhSVN, Reflector and NUnit.
Robust alternative projects
I have concerns about longevity and support on projects from companies and hobbyists regardless of whether they are open source or proprietary.
NDoc, CVS & NullableTypes are three I’ve used which died when an alternative commercial or open source project gained more momentum and SourceForge is seemingly littered with thousands of dead projects.
If a project you rely upon dies you have one of a number of options:
- Migrate to something new (gained little from open source)
- Fix bugs and problems yourself (time spent working outside your business domain)
- Have a support contract with somebody else to work on it (single-supplier scenario?)
Competition is important
Competition is important but I can not, in a professional capacity, recommend to customers something that I believe is less suitable in the interest of keeping the competition healthy.
Confusion about choice
I hit this one first hand developing my final-year degree project which required development of a web site in Java.
The number of choices for Java was incredibly confusing despite knowing the syntax. J2SE or J2EE? JSP, Struts, Spring or another servlet package? What about the database and ORM? Application server? What versions work together? What overlaps? Would I be able to get experienced developers? If not how long to train them up?
.NET has many options too but I can start with the .NET Framework and get right into solving the domain problem. If the going gets tough I may have taken a wrong turn and need a different solution. That could involve choosing an alternative component or framework but now I’ll know what problem I’m trying to solve when I go looking.
Developers on complex projects felt that WebForms wasn’t ideal – it is hard to maintain, the output bloated with leaky implementation (ViewState) but it serves many developers well enough.
Open-source projects such as MonoRail addressed this taking cues from Ruby on Rails. Microsoft acknowledge this and add a similar MVC framework going so far as to support additional engines and components allowing elements of MonoRail to be used. Those guys could drop the glue required to get their engines into the pipeline and just concentrate on engines if they wish.
What works for me
Stay small and focused until you feel friction.
Friction isn’t always technical or immediately obvious. It might be future plans and it’s often people. It might be what isn’t there and will never be.
Time lost on friction is not spent developing your domains features.
If another solution causes less friction, use it but don’t underestimate unknowns.
I guess that’s just being pragmatic.