Benoit_

I don't understand your reactions. Maybe because I am not from the US.

People say: you should NOT hire your partner.

So, you should NOT hire friends? So, you should NOT hire people you like? So, you should NOT hire people for who you have any opinion? So, you should NOT have any hobbies other employees can have?

Our decisions are obviously biased by our feelings, and it's normal, we want people reliable, people we can trust! What's wrong with that?

In some cases, we want objective decisions. In these cases, you should just recognize your incapacity to be unbiased and let other people take the decision.

When I read the blog post, Keith didn't seem to have faced a such case, so non-disclosed his relationship seemed to have been the best decision to avoid to influence other people decisions.

It's common to meet the "love of our life" where we work, I don't understand why it should be forbidden to those who have a management role.

It's not specific to software.

The general issue is that the indirect costs of a product are not supported by the company that created it.

I explain: a company could generally earn more money by releasing new software (or features) than by fixing bugs, even if its users spend more time and money because of these bugs than it would cost to fix them.

We can see it everywhere: - unhealthy foods generating long-term medical care costs - short life products generating cost of buying new ones quickly (built-in obsolescence) - cheap electricity generating thousands of years of waste management - etc

If we find ways to make these indirect costs absorbed, we could improve software quality.

Ideas: - for proprietary software, include a kind of warranty to fix bugs when enough users ask for it (similarly to getsatisfaction.com) - for opensource software, I think of getsatisfaction.com coupled with a donation system to encourage people to fix popular requests

What do you think?

Thank you!

No, I did't have to write native extensions yet. I plan to start another website with "advanced features" (like image manipulation, build of archives, etc), but I think I will try RoR to focus on development rather than on experiments.