The Future of .NET Open Source Software Delivery

Imagine we are awhile into the future. How do you get open source releases down to your project so that you can use them? How do you get the products down to your computer so that you can use them? Is it easier or harder than the way we’ve always done it before?

The Past and Present

Before we can go there, let’s look at what we do now (the past is really the same for us here). Let’s say I want to use NHibernate. What do I do?  There are basically three paths we all follow in this process.

1. Never had product x before. If I don’t have a current version, I have to go out and look for it. So what do I do?

  • Open a browser
  • Find the site
  • Find the downloads
  • Find the particular download I want through the plethora of options that may be presented to me
  • Download it
  • Unzip it
  • Then put it into my project references folder somewhere so I can keep it in source control with my project

2. Use the current version without upgrade. If I have a current version, I may just copy it over and use it in my new project. Nevermind that it is two versions ago. I don’t want to take the time to upgrade because it could be a pain.

  • Open file explorer and find the project with the old version
  • Open file explorer and find the new project
  • Create the structure I need for the references folder
  • Copy the contents of the old project to the new project

3. Upgrade. If I find a bug or I decide it’s time to upgrade to a newer version, how do I get it? Repeat the process of #1 (Never had product x before) and getting the latest version.

Problems with the Present Method of Delivery

It's slow. How long did it take me to get all of that? Yeah, now multiply times every library I want to use.

Too many decisions. I have to make way to many decisions to get the right product and right version downloaded and referenced into my project.

Dependencies may be hard to manage. I may be using projects that depend on the same libraries. In the example above I am using Castle in my project. That got upgraded as well when I got the latest version of NHibernate. Now I may have to test the changes to that. What if the latest version of Castle Windsor I am using is not compatible with the latest version of NHibernate? I won’t see that issue necessarily until I try to run my code. I can try binding redirects, but there is no guarantee that that will work. So now I have a problem. I have to figure out what version of Castle Windsor to use so that I can use the latest version of NHibernate. And this is where dependency management is fully placed on me as a developer. I can now decide to move forward or just continue to use the old version.

Too easy to just continue using the same version you have. It's way too easy to keep using the version you first downloaded and never learning about all of the awesomeness that comes with more current versions of the product.
 
Unfortunately for a lot of people, what I just mentioned with projects that have dependencies on the same things as other projects is the biggest barrier to using OSS (Open Source Software). So let’s talk about the future.

The Future

So now that we have looked at how we currently do it, how will it be in the future?

Open source developers will publish their latest releases to a central repository (possibly in addition to other methods of offering releases).  Then everyone can get their latest releases and develop from there.

Same three scenarios.

1. Never had product x before. Here’s the process.

  • Know what I’m looking for and confirm the name at the central repository
  • open a command line
  • type something to the effect of nu install nhibernate

And I’m done. It’s all brought to me and sitting in my references folder of my project.

2. Use the current version without upgrade. This is still an option. Same as in the present described above.

3. Upgrade. Here’s the process.

  • open a command line
  • type something to the effect of gem update
  • type something to the effect of nu install nhibernate

What Issues Does the Future Method of Delivery Address?

Speed. The process is amazingly streamlined. We are talking seconds as compared to minutes of time to get something. I can now concentrate on what I want to do instead of spending all the time I was on just getting the packages I needed.

The decision tree is reduced. How many decisions did I have to make to get what I needed in the present scenario? How about the future scenario? Greatly reduced.  Less choices to get what I want actually gets me to a decision faster.

I immediately see the dependency changes. All of the dependencies that are required come along nicely with NHibernate. I can immediately see that it downgraded my versions of Castle Core and Dynamic Proxy2. So now I know immediately that I have a problem between Castle Windsor and NHibernate using different versions. It doesn’t solve my problems on this, but it brings it to the surface. So now I can try something like the aforementioned binding redirects.

The process of upgrade became easier than use the current. Another thing you may have noticed. It actually becomes easier to upgrade to the latest version as compared to #2 (Use the current version). That will move people to upgrade, because people will choose the easiest path to get them on their way. And when everyone using the latest version, everyone wins.

The Future Is Now

Oh yeah, the future? It’s now. http://groups.google.com/group/nu-net

Related Posts

Before you comment about “cluttering” the ruby community, please be sure to read this (we’re with you on this):  http://devlicio.us/blogs/rob_reynolds/archive/2010/07/19/gems-for-net-community-response.aspx

Gems - Package Management for .NET 

How To – Gems & .NET & How To – Gems & .NET - Dependencies (References)

Walkthrough - Create Gems Even Easier With a Conventional Build (UppercuT)!


Posted 07-26-2010 1:57 PM by Rob Reynolds

[Advertisement]

Comments

Jon wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 4:08 AM

Whilst I am right up there with the idea of being able to easily add dependencies into your project, I suspect that persuading most .NET developers to drop out of their IDE and pull up a command line won't be easy - I look forward to the day when you right-click on your project in Visual Studio, click on "add dependency" and it offers a list of downloadable software from various sources, installs them and adds them to your project - with the option of adding any referenced dlls to a project folder so that they get added into source control and are available to your CI server.

Rob Reynolds wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 7:44 AM

@Jon: There is a possibility that what you describe could also happen at some point. :D

Chris B wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 7:58 AM

Is this not a description of java's maven in a .net incarnation?

Paul Cowan wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 8:11 AM

@jon - I think it is a sad indictment on .NET that the developers are that crap, they cannot do anything outside of visual studio.  We have to be the only platform this reliant on an IDE .  Very depressing.  If they cannot use the command line then I say stuff 'em :-).

I don't see the delivery of .NET assemblies as that big a deal. To me, it was more important to get all the bits to play together. So I don't see the delivery of .NET assemblies as that big a deal.

To me, it was more important to get all the bits to play together. So if I can deliver non-compatible assemblies via the command line, I don't see what I am gaining. It needs .NET OSS to start versioning.

Ed Blackburn wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 8:12 AM

Jon, if Nu is a success I don't see why what you suggest can't be achieved, Iron Ruby could paper over the crack of devs not installing matz ruby.

The spikes / demos of Open Wrap  VS integration look promising as an alternative, too.

It's good to see some innovation happening in the this space. We need a solution.

Peter da Silva wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 10:51 AM

Pretty much all the open source software I use has a CVS, SVN, or GIT repository already, and on FreeBSD at least I can generally pull the major tools in with "cd /usr/ports/whatever/package ; make". And it doesn't matter what framework it's based on. The differences between the "Java community" and the "C++ community" and the "Perl community" are mostly a matter of style.

The .NET community needs to come in from the cold.

Tore Bostrup wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 11:13 AM

Dream on.  Trying to create a universal repository that resolves all interdependencies automatically and in a fraction of the time it takes to install or upgrade something today may sound good, but the current state of the art tells me it is not realistic without some major breakthrough.  Face it - Visual Studio tries to do this, but in reality it takes a couple of *days* just to install and configure a fully loaded Visual Studio Enterprise development environment.  From DVD (multiple).  And even Microsoft can't quite get all their own updates to work without fail.

Personally, I think we need to move towards stronger encapsulation of smaller components, with a true interface fidelity defined by each assembly, and stronger side by side management, thereby reducing the version compatibility issues altogether.  In fact, I am starting to lean towards small, single purpose apps working together in orchestration.  Loosely coupled individually accessible, or shielded and encapsulated for highly customized solutions.  That would produce the ultimate in agility and the ultimate in flexibility.  If done correctly...

Rob Reynolds wrote re: The Future of .NET Open Source Software Delivery
on 07-27-2010 11:24 AM

@Tore: Yes, the smaller components is one thing I have been talking about for awhile now. The proof is in our ChuckNorris framework, which has a bunch of components that are really good at one thing.

Tony wrote re: The Future of .NET Open Source Software Delivery
on 07-28-2010 10:42 AM

This is not "futuristic", Chris B. is right, Maven does just what Nu is trying to accomplish, and has existed for years now.

http://maven.apache.org/

Rob Reynolds wrote re: The Future of .NET Open Source Software Delivery
on 07-28-2010 11:36 AM

@Chris B and @Tony:  I thought I posted the question. I don't know fully what maven does. I've used it in conjuction with Hudson and I believe it is awesome.   How well does that port over to something like .NET though? Meaning, are there examples of it working already in the .NET ecosystem?

If so, then it could technically be a solution as well.

Rob Reynolds wrote re: The Future of .NET Open Source Software Delivery
on 07-28-2010 11:36 AM

@Chris B and Tony:

The FUTURE  in reference is to the future of ".NET OSS delivery" not in reference to a futuristic tool.  

Community Blogs wrote Creating a "New" Gem for "Nu" - From 0 to 100 in 24 Hours
on 07-30-2010 4:08 PM

Has it really been 24 hours since I jumped on the nu project bandwagon? Sure has. Let’s take a step back

Kris Williams wrote re: The Future of .NET Open Source Software Delivery
on 08-02-2010 7:11 PM

Hey Rob, looking good so far.  I'm sure you are aware of a gem called Bundler.  The great thing about it is that it allows you to lock-in your gem versions using a "Gemfile", and allows you to install them into the "vendor" folder for a ruby app.  Then you put "vendor" into your .gitignore and you're on your way.  I really dislike the idea of storing the lib folder into version control, and a simple adjustment to nu could make it a reality.  Perhaps a .nu file?  Also a quick msbuild task to check nu for installed libs could be cool for automated installation/updating invisibly during a devenv/msbuild.

Rob Reynolds wrote re: The Future of .NET Open Source Software Delivery
on 08-02-2010 11:45 PM

@Kris: Heard of it, been learning more about it and how we can leverage it for Nu.

I like the way you think about the ideas of not checking in libs...it was never really a possibility before.

Community Blogs wrote Unicorns, Triple Rainbows, Package Management and Lasers
on 10-06-2010 2:59 PM

Since the dawn of time, developers have been adding references to projects. Even longer, they’ve been

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Subscribe
Google Reader or Homepage

del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of Devlicio.us
Red-Gate Tools For SQL and .NET

NDepend

SlickEdit
 
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
Unfuddle
Balsamiq Mockups
Scrumy
JetBrains - ReSharper
Umbraco
NServiceBus
RavenDb
Web Sequence Diagrams
Ducksboard<-- NEW Friend!

 



Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers

 

Community Server (Commercial Edition)