+972 52-548-6969
Setting yourself up for failure
John Lam, the guy writing IronRuby, cannot look at the Ruby source code. That is the way Microsoft works. This is setting yourself up for failure, hard.
The main issue that I have with this is that this is purposefully putting blinders on, and then acting surprised because the direction that the project went is rejected by the community.
The Entity Framework debacle is a good example. How the hell can you miss what is going in the OR/M world for the last 5 years? How the hell can you get to the point where you are surprised by the need for persistence ignorance?
Well, the answer for that is simple. You don't look at what is happening outside. This is irresponsible behavior at best, and the reason of a lot of the angst with Microsoft.
Oh, and another thing, if you are actually going to do something in a certain field. Don't go and ask people that have never been in this field. It is highly recommended to ask people who are actually doing stuff in that field, so you can get experience. That way, you don't have to repeat all the same mistakes.
MS MVC is actively doing the reverse, but that is only one project, but I hope that this approach will spread to other teams as well.
Comments
This is an approach that was used by the PC cloners of IBM's first desktop computer. When IBM came out with it they took all but one of the component 'off the shelf'. So all of the components for building a PC clone were available and not owned by IBM. The only thing anyone needed to start making IBM knock offs was this one component, an IC.
In order to create knock offs you need the IBM IC to be 'copied'. In order to 'copy' the IBM IC you needed someone to develop spec's based on what it did. Then you had to hire programmers who never saw or were completely ignorant of IBM's IC to build it from the spec's.
I think MS is in the same mode to produce a 'knock off' that they won't be sued for. Hence hiring 'ignorant' developers. In my opinion they would be better served to provide hooks into open source projects that have already been out in the wild. I develop in C# but I use many open source products in my development process. This has served me well.
Microsoft gets sued quite regularly and they have policies in place that try to prevent this from happening - this is one of them. Big Company, Big Target. All someone has to do is suggest stealing IP and then...
I agree with your premise (up to the point about being irresponsible), but the cause is rooted in our litigious world isn't it - and not a head-in-the-sand syndrome.
Yes, I work at MS. No, I'm not a mouthpiece. Yes, these are my personal views.
According to Frans Bouma it goes both ways: you shouldn't be looking at the MS-RL-licensed .NET Framework source code either.
http://weblogs.asp.net/fbouma/archive/2007/10/04/don-t-look-at-the-sourcecode-of-net-licensed-under-the-reference-license.aspx
Miguel de Icaza also says the same: "People that are interested in continuing to contribute to Mono, or that are considering contributing to Mono's open source implementation of those class libraries should not look at this upcoming source code release."
http://tirania.org/blog/archive/2007/Oct-03.html
In other words it's not just "the way Microsoft works," it's the way any patent-fearing company or individual works. Doing otherwise is setting yourself up for lawsuits, hard.
Rob,
I am aware of the potential problems that you are talking about. And I am aware of the IBM-compatible/black-room approach.
The problem is that this is not just about looking at the code. This is about looking at other things in general.
No one in the EF team has used NHibernate or other serious OR/M for a real project. I am hearing about statements from the EF team made about some of the design decisions that simply had me floored.
Caution is all well and good, but MS had turned into to full blown paranoia, with some schizophrenia on the side.
Oran,
Patents has nothing to do with this, by the way. It is copying violation that you are talking about.
MS RL is not OSS license. It specifically limits your ability to do things with the code.
I guess that you can make the same claim about GPL code, and I would tend to agree.
There are ways around it, such as the black room method, and there are ways to get ideas, feedback and experience that are not related to getting the code.
You are correct that the most obvious risk is copyright violation, but many people believe that the risk of patent violation is also increased, even though you can violate patents without ever looking at someone else's source code. The way I think of it is looking at source code increases the risk of literal copy-and-paste taint (copyright) as well as conceptual taint (patent). Conscientious developers are more likely to avoid the first, while being less likely to avoid the latter.
Oran,
I have never been in a situation where, aside from utility methods, I was able to just rip away a chunk of code from another code base without major headaches.
I find it easier to get the ideas and then write my own from scratch.
Yes, looking at the source code may lead you to the same solution, which is patented, but I don't think that you need to do think about it, and I doubt that it significantly raise the cost that you have there.
Comment preview