Sam Varghese
Thursday, 13 March 2008 22:33
Opinion and Analysis
Page 4 of 5
Former
MySQL developer Arjen Lentz, who now runs his own consultancy named
OpenQuery , saw some benefits. "It would become possible to review implementation of parts of the API,
as documentation often does not reflect reality. That would benefit interoperability, and quality/functionality of non-Microsoft software for Windows, as it would be able to use the Windows API as effectively and extensively as Microsoft itself. So that would be very good, and it would benefit Microsoft itself, Windows as a platform, and its users."
But, he said, there were other considerations: "Publishing source code is not the same as having an OSS development model. Would patches be accepted? Would everything be released, so that people can rebuild the whole from the source parts? Otherwise it's not even verifiable whether the code you're looking at is actually the same as what's used in the Microsoft builds. In addition, it would allow the community to build a binary that incorporates bugfixes and (experimental) improvements.
"That would improve quality and the overall process of things, as it would encourage Microsoft to deal with submitted patches (as there would be alternative builds out there with it anyway) and the ability to build allows more people to test fixes and improvements, so that means that 'final' patches will be better in quality as well."
Lentz pointed out that even OpenSolaris had some closed source parts, due to external licensing factors. "It's likely Microsoft would have similar issues if it were to look at opening up Windows. That is not a deciding factor though, as long as the modular components can be (re)built by third parties. Some developers would never look at Windows code, for fear of IP encumbrance. Others would."
Business analyst
Sridhar Dhanapalan , an active FOSS advocate, said the impact on FOSS would depend on the circumstances under which the code was released. "Windows code is already available under Microsoft's 'shared source' programme. In this state, you must sign a restrictive NDA to see the code, and after that your mind is forever tainted with Microsoft's intellectual property. Write anything even remotely similar to the code you were allowed to see, and you leave yourself open to litigation. In other words, taking part in shared source is a sure-fire way to torpedo your career in software," he said.
"Microsoft have for years been experimenting to find a licence that they can convince people is 'free enough'. Fortunately, they haven't succeeded. The danger if they did would be to shift the balance in the open source world away from free software and towards a model that is more restrictive but still accepted. They have enough code to seriously upset the balance, ignoring for the moment the complexity (which includes also legacy cruft, bloat and so on) and hence difficulty for anyone to actually comprehend the code and participate in development.
"Quality (or rather, lack of quality) aside, Microsoft's code could be useful to see how formats and protocols are implemented. Linus Torvalds once wrote, 'A spec is close to useless. I have _never_ seen a spec that was both big enough to be useful _and_ accurate. And I have seen _lots_ of total crap work that was based on specs. It's _the_ single worst way to write software, because it by definition means that the software was written to match theory, not reality.' It's one thing to have documentation (as the Samba team have recently managed to acquire), but there's nothing to guarantee that there are no mistakes or deviations (intentional or otherwise) in the actual implementation. The WINE project is a classic example - consigned to faithfully reimplement all of Microsoft's bugs, even if they run counter to documents you might find on MSDN."
