Proponents of the free and open-source software development model are using the recently announced delays in the shipping of Microsoft's Windows Vista and Office 2007 products as an example of how the company's software engineering process simply does not work well. They are also pointing to how it stands in direct contrast with the way software gets developed in the free and open-source community, and using the delays to explain why theirs is the better choice.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-11-14
Actually, kernel 2.4 did have an expected release date
Which is not the same as a date on a roadmap as MS.
Which did not prevent any Linux kernel user/business from taking the development version and deliver a product based on it.
Which is not the same as MS, as customers have not paid a subscription license to have discount on Linux kernel when it's out.
Which is different, because Linux "execs" did not make bold statements beforehand as to how they will be so far ahead of everyone.
And so on.
There are no official release dates set for the kernel. You know why? Because it is a convinient way for them to be able to avoid the kind of criticism that Microsoft gets
No, that's just because it's FOSS made by benevolent people, not by a company, but this has escaped you completely.
You apparently can't understand FOSS, having to take it as a company to grok what it is about.
Can you imagine the kind of heat that Microsoft would get if they just said "Vista will ship when it ships." It simply doesn't work that way when 96% of the computers in the world run your software
96 % of the world's computers don't run MS software (due to the fact that MS software is limited to MS OS), far from it, get your facts straight.
I agree with the rest : deceit through delayed and delayed release dates is better, especially when businesses paid licenses to have discount on an OS that won't be out during the time frame they paid for.
They are not red herrings at all--especially some versions of the Linux kernel. It is an example of a product that was delivered nearly a year after it was expected to be ready
You seem to have difficulty understanding the difference between "expected to be ready" and "announced date of release".
One is your guess, the other is backed by the entity releasing the product.
And note that I never said that Perl or Wine had a scheduled release date. I said that they have failed to deliver releases in a timely fashion, which is perfectly true
Which is perfectly wrong. Sorry, even businesses have put out products based on the numerous releases of Wine. Perl have made numerous releases too.
If you really believe what you say, it only shows you really don't understand a thing about development.
The beta status of Wine is just a facelift.
Sorry, I don't consider 10 years to a beta release
That's because you don't realise what a "beta" release mean, especially in the case of Wine. Cedega, which is an old product not in beta, is using Wine, appliances are using Wine too, CrossOver Office too, ...
6 years since development started on Perl 6 with no release date even on the radar yet to be speeding along
As was intended. And Perl 5 is still actively developed. You're completely wrong anyway, you talk like lots of Perl resources were on Perl 6 (like MS with Vista), which is just not true.
The problem is not in the development models of either MS or open source
I'm not qualified to discuss that. I disagree with people saying "Linux advocates" do this or think that, like in this stupid article, anyway.
The problem is that software engineering is one of the most complex activities humankind has ever undertaken
BS.
And to this day, we still don't have very good ways to control complexity
BS again.
I don't care how good your tools are. When you have a few million lines of code in a few thousand source files that have 50 or 60 dependant libraries, each of which also has hundreds of thousands of lines of code, this stuff just gets very hard to manage
Which is so if you didn't follow basic good practices of engineering, which seems the case at MS, contrary to what I hear constantly from MS and its shills : they listen to customers, they do strict QA, they innovate, they have the best IDE, ...
Member since:
2005-10-08
"They have not.
There is no release date road map for Linux kernel, only Linus saying some dates because people (mostly journalists) pressed him to do so."
Actually, kernel 2.4 did have an expected release date. And they ended up missing it by about a year. And yes, you are right. There are no official release dates set for the kernel. You know why? Because it is a convinient way for them to be able to avoid the kind of criticism that Microsoft gets. Unfortunately, Microsoft just doesn't have the luxery that open source does. Can you imagine the kind of heat that Microsoft would get if they just said "Vista will ship when it ships." It simply doesn't work that way when 96% of the computers in the world run your software.
"But I'm not surprised all you have is red herring like Linux kernel and Wine."
They are not red herrings at all--especially some versions of the Linux kernel. It is an example of a product that was delivered nearly a year after it was expected to be ready.
And note that I never said that Perl or Wine had a scheduled release date. I said that they have failed to deliver releases in a timely fashion, which is perfectly true.
"the FOSS crowd speeds along in development with their inferior tools"
Sorry, I don't consider 10 years to a beta release, or 6 years since development started on Perl 6 with no release date even on the radar yet to be speeding along.
The problem is not in the development models of either MS or open source. The problem is that software engineering is one of the most complex activities humankind has ever undertaken. And to this day, we still don't have very good ways to control complexity. I don't care how good your tools are. When you have a few million lines of code in a few thousand source files that have 50 or 60 dependant libraries, each of which also has hundreds of thousands of lines of code, this stuff just gets very hard to manage.