Open.NET — .NET Libraries Go "Open Source"

An anonymous reader writes "whurley just posted a blog about Microsoft's announcement To Make .NET Libraries available under a crippled 'Open Source' program using their new Microsoft Reference License. The post includes the official pr doc from Microsoft as well as several points about how this really isn't open source. One example: If a developer finds a bug in the code, rather than fixing it themselves and submitting a patch to the community they'll be encouraged to submit feedback via the product feedback center."

Comments

Could be worse

[east coast]

they'll be encouraged to submit feedback via the product feedback center

In some ways I'd rather see these things organized "under one roof". As long as the product feedback center is responsive I don't think this is going to be a big deal for most.

Re:Could be worse

[CaymanIslandCarpedie]

Fair enough, but Microsoft is trying to get street cred through a disingenuous use of the term "open source".

Except if you'd read TFA you'd see MS never even mentions the term "open source" or anything like it. They are very clear on what is and isn't offered and it being open source is certainly not one of thier cliams. That term come from a blog.

Unemployable?

[overshoot]

Then there's the fascinating question of future employment prospects once you've seen the "crown jewels." A key part of copyright law is whether you've had the opportunity to copy the material rather than recreate it (clean room.) Keeping your developers "uncontaminated" can be a tricky business.

Being exposed raises some serious issues regarding the future employability of the "exposed" developers.

Re:Wow, this is pretty good news.

[blincoln]

Being able to see the source means that you can take the present tool kit and work around any bugs in a deliberate manner. Whereas without the ability to see the code you have to hope that the bug is what you think it is.

I would go one step further and say that it also lets you understand the behaviour of the framework where the documentation is inadequate or missing. I can see this being very useful, especially for those of us who like to fool about with less-commonly-used parts of .NET.
I also think that in the larger view, this is a great indication of shifting mentalities at Microsoft. I was pretty surprised to read "The security of the .NET Framework does not depend on the obscurity of the .NET Framework source code" in one of their press releases.

Re:Slashdot spin at its finest

[Todd Knarr]

It does introduce a big problem, though. Suppose someone's seen Microsoft's code, and in code they've written there's a stretch that's suspiciously similar to Microsoft's code. How does one go about proving that they didn't copy that code from Microsoft's in violation of the license? Access may be great for the programmer themselves, but if I'm not them and I'm using their code I suddenly acquired a big headache. And for me this isn't a theoretical excercise, I've been caught up in a lawsuit about exactly that sort of illicit propagation of code. I'd have to recommend not employing anyone for .NET work who's agreed to that license, and not using any .NET code created or touched by anyone who has, unless and until we've gotten our own license covering the Microsoft code in question. Anything else leaves too many legal question marks that're too easily avoided by just not tempting fate.

Re:IT a Trap! (Step 1 to kill Mono)

[Mongoose Disciple]

Out of curiosity, how much work have you done with Java and C#?

C# is to Java as Java is to C++ as C++ is to C on to infinity. To say that C# is just a copy of Java is about as much true and about as much false as saying Java is just a copy of C++. It is, and it isn't.

In each case you have a "new" language created based strongly on an old one, benefiting from the "mistakes" of the previous language.

The tricky part is, what's a mistake in the design of a language varies depending on your perspective and what you're trying to do it with -- and so the "evolved" language ends up better for some tasks and worse for others. Java addresses a ton of things that C++ doesn't do well (or require a much more seasoned C++ developer to do well), at the cost of becoming unsuitable (or at least, less suitable) for some uses, such as embedded programming or high-end game programming.

C# is that same kind of quasi-evolution from Java. It makes some things a lot easier to get right, but at a cost of giving up some of the things that are good about Java. The key here is that the differences between the two aren't as much in the base language's syntax as in the core frameworks/libraries that are built around them. That's what makes the chance to see more of what makes those libraries tick and why they made the design decisions they did interesting.

Re:Could Be Better

[Frostalicious]

What issues are you talking about exactly? I've worked with .Net for six years and am unaware of "all kinds of issues"

Maybe he's talking about the IDE. I've run into lots of junk that hasn't been fixed for years. Things like .lic files becoming corrupted, loosing the ability to type non-word characters, source safe integration breaking, files in the .Net temporary directory getting locked, and projects loosing the ability to load DLLs. These are all design time problems, so my impression was they got a low priority and MS just decided to let us live with it.