Technology Selection: An Open RFC

I was going to wait a little while before talking more about technology selection, but then I realized that I could include everyone in the process.  In case you're not up to speed you should read about The Product Idea and some of our thinking about what technology to use in Technology Selection: Sharepoint?  Anyway, on to business.
I'm plodding forward with my research on what technology makes the most sense for us to use.  I'm doing most of the primary research with feedback from The Style Czar and The Adept (info on the characters in Introducing the Players).  At the moment there are a number of options under consideration (in no particular order):

1. Develop the system in C#.NET
2. Develop the system in Ruby on Rails
3. Grab an open source CMS and modify it to suit our needs
4. Develop a client heavy system which uses javascript/xslt (still in browser) and whatever web services framework is most convenient to serve up the data.
5. Other options?

Before I get into a little analysis of pros and cons, let me give you the bias of the team members.
The Style Czar heavily favors the use of Rails.  He's used some of the open source CMSes and is convinced that it will be a terrible pain to modify them to our needs.  He also wants to avoid .NET since he generally likes to stick with open source.
The Adept heavily favors the use of C#.NET.  He works with it professionally so any work done here will enhance his working resume.  Without the need to learn another language and web framework he'll be saved valuable time.
I'm leaning towards the Rails approach.  I really like what I'm seeing so far and it seems ideally suited to bring our project to life.  Also, I'd love to start working professionally with a new language.
Now I'll try to outline the pros and cons of each approach in a little more detail.  Please feel free to add your pros, cons and comments for each one.
Develop in C#.NET
Pros:

• no learning curve for The Adept and I.
• fully featured development tools.
• extensive development community with plenty of support and articles.
• continued development of .NET resumes for The Adept and I.  Not really business related but it is part of our considerations.

Cons:

• compiled code base.  You'll remember that one of our requirements was quick and constant updates.  I have concerns about redeploying the entire compiled app for every update.  Scripting language options don't seem to have this weakness as we can update each individual piece without affecting the deployment of the whole.
• expensive development tools
• server licensing costs
• I'm not sure how easy it will be for The Style Czar to make visual changes post deployment.  This one I'd like to get some feedback on.  If you're developing web applications for .NET, how easy has it been for your designers to change the visual things?  For me this process seems fairly static, with the designers creating a look and feel up front and the application developers conforming to that.  Then a final run through after it's functionally complete.  This just doesn't seem to fit with our whole idea of agility.

Develop in Ruby on Rails
Pros:

• Designed to create systems similar to this.
• No development licensing costs (unless we go with ArachnoRuby and even then it's cheap).
• No server licensing costs.
• Rails seems very up to date with Prototype and script.aculo.us integration.  This will help us with the whole web 2.0/AJAXification of our system.  Note:  I know they can be used independently of Rails, but there seems to be more traction here.
• Chance to get in with a new and exciting development community.  This one is just mine and not really business related, but for me it's a real pro!

Cons:

• lack of sophisticated development tools.  I can't seem to find the IDE, debugger options that make things easy.
• new language and framework for the team to learn.
• There seems to be development work going on already in the arena of Rails based CMSes.  Jason Fried mentions an upcoming release in this interview.  The Rails site even has a wiki about the subject.  This may not be an issue since we don't plan on developing this as a shrink wrapped app.  At the same time, I'd think that 37Signals would plan to release the thing as a managed app since that has been their business model (since switching to being an ISV) so far.

Modify Open Source CMS
We've basically ruled out the option of modifying an existing OSS CMS. We feel that if we're actually going to create a fairly new user-centric CMS, it should be from scratch.  There's too much danger of inheriting all the flaws that we think exist in the current crop of applications.  Another issue is that most of them are in Pearl, PHP, or Python; none of which are very familiar to our team.  There's also a fun factor of getting to architect the system ourselves.
Develop Client Heavy System
We've also ruled this option out.  It seems overly complex and could have way too many problems.  While whatever option we go with will include a decent amount of client side javascript we won't rely on that entirely for page rendering.

That's the basic run down as it stands right now.  Were we too quick to rule out two of those options?  Are there other options we should be considering instead?  Are we taking too much time thinking about what to develop this in?
Whatever the answers to those questions, a decision will be made no later than a week from end-of-day today.

Comments

[Michael Sica]

RoR vs. .Net?

If you like IDE's that do a lot of the work, go .Net.

If you like to work with the smallest possible amount of code and configuration, go RoR.

Actually, just go Ruby on Rails. It seems so much simpler than .Net. Not to mention, you'll have a better chance of the future versions working across all the browsers. Not to mention, it's FREE.

[Dharmesh Shah]

I'm going to suggest revisiting the .Net issue. The challenge with RoR and other such paths is that 5+ years from now, its often the pervasiveness of a language/platform that determines it success. Much of this is contingent on your long-term plans, but I'd argue that the odds are in you favor of picking a "pervasive" platform (like C#.Net) as the odds of it still being "in favor" a while from now are much higher.

[Ken Dyck]

Chance to get in with a new and exciting development community. This one is just mine and not really business related, but for me it's a real pro!

Don't discount the community. An active development community can help you get your product done sooner, which is generally good for business.

[Collin]

I recall reading your original post about this product idea. I have also been watching another MicroISV which just released it's product last week with GREAT success. That was the statistical program called Mint which I believe runs on PHP and various databases.

With the success of that product it has made me really rethink the value of ASP.NET for my own software. I am continuing my course since the product as already been 60% written and also my product is not deployed across multiple servers and is a hosted solution that I will control and maintain the servers for.

But here is why I think PHP probably shouldn't be thrown out yet. First, from ASP I was able to get a good feel for PHP after a week or so. The learning curve was really not that bad. As far as the market goes right now for your product you probably have more reason to focus on a unix/linux friendly system instead of an MS server environment. Which might actually be an argument for Ruby as well. But then PHP and probably Ruby may have ways to make it easier to port over to an MS machine later.

I've always been a Microsoft fan so really it pains me to look at it this way but I can't help but realize that not everyone wants to pay $150+ a month for a web server and database. Sure there are cheaper solutions but none have ever lived up to my expectations.

Considering your product idea has Mr. Regular Joe in mind you should also keep in mind that the majority of personal sites are probably on virtual hosts that support php/mysql.

Really you should do some research on your own and develop for the masses. I have no idea who your true target audience will be or what you place to charge.

SO, I say go with C#.. err.. PHP. err.. Python sounds nice.. err Python is a part of Zope.. err. .damnit.. I'm all confused, what was the question???!?!

[Paul Dix]

Well this is all good stuff. One comment though. The pervasiveness of a platform (C# vs. Ruby). I don't factor this into the equation at all. Since we're an ASP, we don't have to worry about the platform except on our own servers. As further proof that popularity of the programming platform isn't important with this type of business model, I point to Paul Graham and ViaWeb. They built on LISP, which is hardly pervasive in the professional web development world.
Having said that, I'm still really debating the decision and doing more research. However, I will have to make some sort of decision by end-of-day Tuesday. I'm planning on getting a bunch of research done this weekend. I'll keep you posted!

[Paul Dix]

Collin,
lol. That's how I feel about now. Well something is moving forward soon. Then I'll just have to make whatever I pick work for me. Btw, I noticed the launch of Mint but was unable to demo the produdct. Did you get a chance to actually demo it?

[dema]

Hi Paul,

If you wan´t some info on the RoR vs ASP.NET debate, I´ve written a series of post on the subject on my blog:
http://dema.ruby.com.br/articles/category/ruby-on-rails-vs-asp-net

My opinion: go with RoR.