Listen: Pay attention to what your customers are telling you.
Understand: Take the time to understand what your customers are telling you.
Respond: Follow-up to what your customers are telling you where and as appropriate.
Repeat: Keep listening, understanding, and responding to what your customers are telling you.
Following the LLUR Principal: Bad Example
PM : FooBar Project : Eveel Empire
“We’re sorry our buggy software has blocked progress on your project. If we get around to fixing it we’ll release it in a service pack, but if it happens we’re not sure when that might be. What do you want us to do? Our resources are “limited”!
Customer : BarBaz Project : We’re Not Eveel (At Least Not Yet) Startup
“If you gave me access to the source, I could just fix it myself”
PM : FooBar Project : Eveel Empire
“Bwaahhhahahaaa!!! Wait, you’re serious, huh? Bwaahhhahahaaa!!! That kills me! :D :D :D”
Following the LLUR Principal: GoodGreat Example
ASP.NET MVC Framework Road-Map Update - ScottGu’s Blog
Starting with this next preview, we are also going to make the ASP.NET MVC Framework source code downloadable as a buildable VS project solution. This will enable you to easily view and debug the ASP.NET MVC Framework source code. We are also going to include a license that permits you to optionally make patches to the ASP.NET MVC Framework source code in the event that you run into a bug in an application you are developing with it.
The license won’t enable you to redistribute your patched version of ASP.NET MVC (we want to avoid having multiple incompatible ASP.NET MVC versions floating around and colliding with each other). But it will enable developers who want to get started building ASP.NET MVC applications immediately to make progress - and not have to worry about getting blocked by an interim bug that they can’t work around.
There will be little patching going on because few will want to merge local changes with the next code release. I think in practice this is barely a step forward from using reflector.
Scott hides behind "legal issues" where in practice it's nothing more than "not invented here" mentality which is predominant in every piece of code MS releases. Sun doesn't have a problem working with community, MySQL doesn't and neither do many others.
MS has already released the source the .NET. It's pretty obvious that MS is worried about forking and community actually improving on their horrific code base.
Have you tried to figure out how to test ASP.NET pipe line? Half of the public classes have internal constructors and half of the overloads are internal as well. What really gets to me is that it's just inconvinent... you can easily execute all that code and being internal or private just gets in the way and nothing more.
@Alex,
>> There will be little patching going on because few will want to merge local changes with the next code release. I think in practice this is barely a step forward from using reflector.
Your entire argument rests on whether or not people will patch the code based on concern with having to merge their changes once the next update has been released. I think you're missing the point: What this does is open up the door for people to fix bugs that are blocking their progress while at the same time opening up the door to potential community contribution.
In addition to this, there are 100's upon 1000's of IT professionals out there who have been pounding on MSFT's door to get them to fix all sorts of one off bugs -- in production code -- that they could just as easily fix themselves if given access to the code. This isn't an issue with redistribution; This is an issue with being given the freedom to take matters into your own hands and fix issues *NOW*.
From a security perspective, how many analysts out there do you think are watching this move from MSFT with great anticipation, encouraging them to continue this trend such that when problems arise -- just like the OSS communities -- the problems can be patched immediately while an official release is being developed and tested.
Of course, to ensure that there are not 100's upon 1000's of patched assemblies finding there way out into the wild -- wreaking havoc on the update ecosystem as a result -- specifying that you can not redistribute the patched code ensures that this doesn't became Yet Another Problem That Needs To Be Fixed, but this time in reverse.
You're looking at this from the Free/Libre Open Source Software perspective. That's not what this is about. This is about fixing a gaping hole in the proprietary software ecosystem. This is *HUGE* deal! Maybe not as it relates to FLOSS, but not everything has to relate to FLOSS to be considered a positive move in the right direction for MSFT.
I do agree that some source is better than none. However...
I think debating benefits of community source contribution is pointless. I has been proven for decades that the model works successfully. You can't introduce any problems by just allowing people to publish, download and build patched code.
Considering the overall size of the .net community, the read-only license will benefit a very small group. If you can't publish your patches on your blog, people will end up fixing same issues over and over again. This model doesn't help the project at all, it only helps those who need an immediate fix and the fact that it discourages knowledge sharing is even more counterproductive.
@Alex,
>> I think debating benefits of community source contribution is pointless.
I'm not debating the benefits: The benefits are obvious.
>> I has been proven for decades that the model works successfully.
Absolutely!
>> You can't introduce any problems by just allowing people to publish, download and build patched code.
As far as I can tell, there's nothing stopping anyone from publishing their patches. They just can't redistribute the combined result.
>> Considering the overall size of the .net community, the read-only license will benefit a very small group.
This isn't a read-only license. This is a read-and-modify, but do not redistribute the combined result license.
>> If you can't publish your patches on your blog, people will end up fixing same issues over and over again.
Agreed. I guess we'll have to wait and see what the license states when it's released, but I would be surprised to discover that MSFT will disallow publishing patches.
>> This model doesn't help the project at all, it only helps those who need an immediate fix and the fact that it discourages knowledge sharing is even more counterproductive.
How does it discourage knowledge sharing? If anything a non-redistribution license *forces* knowledge sharing because there's no other way *BUT* to share the knowledge rather than just the end result of your work. I realize that's splitting hairs, but none-the-less, that's what ultimately becomes of a non-distribution clause: You can use the knowledge gained in your own work, but whatever work that is must be original in it's foundation.