For public free software projects, there are plenty of cloud based VCS and issue tracker; google code, github, indefero and bitbucket come to mind.

Otherwise, for private projects you may wish to have a look at the turnkey linux images for project tracking
http://www.turnkeylinux.org/project-management

I see they have redmine and trac images. It hardly gets easier to set up than an turnkey vm image!

supporting software indefinitely is like buying a car and asking for infinite replacement of parts forever.

But I do agree on a small "warranty" period, which may range from a few months to a year, just so that most bugs gets corrected but after that it's "mechanic billed by the hour".

yesterday I stumbled on http://www.boingboing.net/arcade/ which presents a few games which are mostly html5. Since a lot of people are choosing html5 over flash I believe we'll see more and more of them coming in the future.

value = $ / (enjoyment x hours)
I believe this would be the correct formula to determine what a game's worth, as only $/h is really a wrong metric for a something we don't enjoy.
But this leads to the real question: How can we measure how much we enjoy a game? We can replay a game and enjoy it the same the second time or just be bored as it gets repetitive. In the same way, we may not really enjoy level grinding because mechanics get repetitive during the first pass.

After many readings and discussions, my definition of "enjoyment of a game" is trying to find patterns in a game and establishing a strategy. The human brain is apparently good at this and "provides satisfaction" when finding a specific pattern. As long as I'm trying different things and as I'm not stuck in a local maxima I'm enjoying something because of the impression of improvement. For this reason, there are repetitive tasks that are classified as fun (like RPG level grinding) as long as there are patterns to be found (like finding the most efficien levelling path).
But it's not always directly related to pattern finding as much as "self improvement". A musical rhythm game has a duration of fun, as long as I have a feeling of improvement. So I had a lot of fun during the 2 first passes as I was getting better, but then started having similar scores for trying again, and it got less fun. So the net value would be cost/(2*game time).
As a counter example, in a racing game, there are less patterns to be found and less self improvement; yes, you can buy new/faster cars ingame but play the same level in the same conditions and you won't necessarily get better. That I would evaluate as (cost*2)/(game time).

The above examples are obviously totally arbitrary and I intentionally do not mention any game name as the values are different between individuals (unless you have the exact same learning rate as I do). But I hope it helps some of you clarify your metric of what's a game worth.

If I go back to when I started programming, my first goal was to create a game. It didn't matter at the time whether I was using some proprietary stuff like VisualBasic or older language like c or pascal. I had a goal in mind, which was to be able to control a simple sprite through a grid and I wanted to do it the simplest way that was possible. I still think the topic of first language is about motivation. You want to do something like you see. You don't necessarily want to learn a bunch of abstract design concepts like OO, design patterns. I needed something trivial and visual, yet extensible enough to allow me to add features I thought cool. VB was an awesome opportunity at the time as I could use drag and drop to manipulate objects and even though I was only manipulating widgets in a simple way, it allowed me to do all I required, even the more complex project ideas that followed.

If I look at today's alternatives, I see squeak that does right that, backed by the great smalltalk language. It is simple and visual, yet offers great flexibility. If I had Squeak as a choice when I started, that's probably what I would have chosen.

But it's all about motivation. Someone needs something of interest to work on and use the right tool for it. Programming is an art. You paint for yourself. And you learn to like painting. Then you try other styles: abstract, sceneries, portraits. And once you master enough your technique you can think about painting for others.

• they always jump in front of you when you least expect it
• unless you have nothing of value they are always eating and scratching stuff
• they don't care about the number of hours you slept when they meow and you're sleeping.