Comments on: Microsoft targets amateur programmers

Perks for hobbyists will include lightweight development tools and a free version of SQL Server.

[cballinger]

May be to late

Often wondered why Microsoft doesn't sell their software to developers or student/wanna learn something new individuals at the same price they sell to their employees. With the economy the way it is their subscription prices, etc. are just to high to justify for the student or someone wanting to learn the MS tools. Like Oracle, SUN, etc. they seem to be missing the boat. Make your product reasonable so individuals can purchase and their influence in the marketplace becomes a formidable force to deal with. Apple used this technique for years by giving or selling their systems to schools, only to then raise prices so high that as the students who grew up couldn't afford to go buy an Apple and the associated software, so they switched to PC's.
Sounds like the martketing types are spending too much time in the classroom and not enough in the real world to see how things work.

[zaz.net]

You've got it!

That's exactly it. Availability of high end tools to the novice programmer is what drove the growth of Windows in it's early years. I remember running DOS and hardly ever running Windows 3.1 because there were no useful applications for it. Microsoft pushed tools into the hands of developers back then, and Windows use skyrocketed.

They will continue to have a hard time trying to match the price of the Linux tools, but they have a huge head start on what their tools can do over the free Linux tools.

MS needs to push the new developers into using their products or risk losing more market share.

[arthur-b]

OCOA

Overall Cost Of Application

Oh my, just like as was/is the case with Access and those macro's in various Office files I forsee a whole new legion of wannabee code warriors who for all the right reasons in various wrong ways craft together automated gadgets that slowly but surely grow into department vital processes and from there on into enterprise vital processes that somehow get overlooked time and time again (but do require ever increasing budget and man hours). Yet remain poorly documented (if any), almost impossible to support, very difficult to migrate or upgrade, and somehow finds it way and hooks into all sorts of other automated gadgets that slowly but surely etc etc.

Look, I'm not saying that for the stand-alone, 'quick and dirty', automated task one should put together an entire development team. But one should also be aware that certain tools should only be taken so far before being replaced by more professional solutions (which come with very different price tags included).

Ask anyone who had the 'pleasure' of 'upgrading' certain products enterprise wide within a given time-frame and for a given budget. It's absolutely unbelieveable how creatively (with the best intentions nonetheless) people can get while totally ignoring very important (business) things. And I'm not entirely sure if such automated tasks are the best basis to get 'upgraded' into a full scale enterprise solution 'as is'.

In short: don't get hooked. Control these things before they get out of hand.

[infochen]

Why I am interested

I am chasing Microsoft to find out when this will begin shipping. I am currently developing intranet applications for my company and I use the LAMP 'framework' (Linux, Apache, MySQL, PHP5).
Off lately I see two new initiatives that will shape the future of my type of application development. Firstly , I think it is worthwhile looking at the following forum thread on the Zend website : http://www.zend.com/phorum/read.php?num=6&id=1323&loc=0&thread=1323
which is no big surprise following the latest trends in the future of PHP ,
and secondly I see a lot of focus on the Mono project which would bring development together in a uniform 'framework'.
Anxiously awaiting Microsoft's response..

[arthur-b]

customer view

The general problem with Microsoft only (or preferred) applications developed by third-parties is the (hidden) price tag (or strings) attached to it as far as the customer is concerned. Certainly in the long run.

Think life cycle, support issues and future migration cost for one.

Quite frankly, in my view, any developer who doesn't respect such (customer) obstacles is doing his/her customer a disfavor. The average customer would like to purchase a product and let it do its thing for many years to come. Not to experience the cascading effects of upgrading (or even implementing) one thing and then be forced into upgrading a lot more because of this or that or whatever.