This Is Why I Don’t Like Microsoft’s Way Of Open Source Development
Posted by Davy Brion on August 3rd, 2009
We’re currently using our own custom little IOC container in Silverlight, mainly because Castle Windsor isn’t supported yet. One of the features that our IOC container has (and is based on a feature supported by Castle Windsor) is that of ‘automanual dependency injection‘, which basically enables you to resolve a component through the container, while overriding one of the dependencies with a parameter to the container’s Resolve method. This is a feature that we need, and switching to a container that doesn’t have it would break a very large number of classes (basically all of our controllers) in our Silverlight applications.
Today, i figured i could replace our custom IOC container (who wants to have a custom IOC container in his codebase anyway?) with Microsoft’s Unity container, which is supported on Silverlight. Turns out that there is no way to resolve a component through Unity while overriding one of the constructor dependencies of that component. Bummer.
But wait, Unity is open source, right? So i go over to Codeplex and browse the list of recent check-ins of the source control repository. The last release of this project was on October 28, 2008. It’s most recent check-ins are dated July 13th, April 20th and December 1st. With such sporadic check-ins (which are more like periodic synchronizations from Microsoft’s internal source code repository) there’s no reason to even begin working on a patch because who knows when you’ll get a code drop that officially has the patch.
That is, if the project even accepted patches. There were 3 patches submitted, and all 3 of them were declined with an “This project does not accept public code contributions” message.
So let’s see… i can request a feature, but there’s no guarantee that it will be implemented. Even if it were implemented, i’d have no way of using it until they decide to bless us with another code drop. I also have no way of providing the feature myself and contributing it to the project, unless i keep it privately and keep maintaining it for every new version they release.
I don’t care what license they put on it, but you really can’t call this Open Source development.
August 3rd, 2009 at 2:37 pm
I’m not really sure I understand the complaint. You can download the source, and patch it yourself, and then use your patched code to your heart’s content. The project doesn’t accept patches, but even if it did, there’s no guarantee that your patch would make it in to the release– do you think the Linux kernel accepts a lot of patches from random users/developers?
What is it you are expecting, really? How is it that Microsoft is stopping you from doing what you want to do? How is “Microsoft’s style of Open Source development” different than any other Open Source project with a gatekeeper and a high bar for acceptance of new code?
August 3rd, 2009 at 2:52 pm
@Michael
“How is “Microsoft’s style of Open Source development” different than any other Open Source project with a gatekeeper and a high bar for acceptance of new code?”
For starters, most open source projects are pretty willing to accept patches if they are of a high enough quality. And from what i’ve seen from the Unity source code, coming up with a patch that is of high enough quality definitely shouldn’t be a problem. But with Microsoft’s open source projects, patches won’t even be considered.
So if you do decide to patch it yourself and use your own modified version, you’re pretty much forced to keep patching any future release they put out because you obviously depend on the patch. But since the development is pretty hard to track (a quarterly code drop isn’t really sufficient IMO), it really becomes a pain in the ass to do so.
And seriously, why do they even release their ‘open source’ projects on codeplex? The source code repository is almost never up to date, they don’t accept patches, they usually have their internal issue tracker… how is any of this ‘open’?
You can look at the code, and theoretically speaking you can modify it but please, let’s not pretend this is any kind of open development, alright? This is strictly one-way traffic, which definitely isn’t what open source is typically about.
August 3rd, 2009 at 3:24 pm
You’ll definitely want to take a look at Autofac–a popular IoC container which supports what you’re looking for within Silverlight.
August 3rd, 2009 at 9:05 pm
Er, it’s Ms-PL. You’re expressly permitted to 1) create a derivative work with whatever enhancements you need 2) distribute the derivative work (under Ms-PL). You could call it Commonality or something.
August 3rd, 2009 at 9:17 pm
The license doesn’t mean anything if contributions aren’t even considered. That’s what open source development is all about. The ability to fork is really the last possible alternative you’d want to consider when it comes to open source development.
It’s kinda like those people who thought Microsoft’s recent contributions to the Linux kernel shouldn’t be accepted… that kind of thinking simply doesn’t make any sense.
And why on earth would you take on the burden of forking when you can go to another truly open source project to get what you need?
August 3rd, 2009 at 10:26 pm
> We’re currently using our own custom little IOC container in Silverlight, mainly because Castle Windsor isn’t supported yet
Send us the patch
August 3rd, 2009 at 10:33 pm
@Krzystof
it’s a very basic and simple IOC container implementation… haven’t looked into trying to get Windsor working in silverlight but i’d be willing to try to help though. I’ll contact you through email about what needs to be done…
August 3rd, 2009 at 10:34 pm
and now the actual comment.
I understand your frustration. This is what Scott Hanselman calls, not Open source, but source in the open. IIRC that’s exactly how other MSPL projects work, like ASP.NET MVC, or MEF. The code is available, for you to read it, and give them feedback, to plug it to the debugger… but that’s it.
I just don’t treat it as an actual Open Source. on the ‘why bother’ note, well – it can be useful sometimes… if you treat it more like reference source.
And in the final note, don’t even waste your time for Unity. it’s such a PITA to work with.
I have a great idea – [hint]Castle Windsor does accept patches! [/hint]
August 3rd, 2009 at 10:46 pm
Why bother? Just fork the project. That would happen to any such (truly) Open Source effort that didn’t accept patches. The biggest example I can think of right now was when frustration with the X11 group lead to the X.org fork, which is now the default in most Linux distributions.
If the only choice is to support your own patches against the “official” version, or build your own, then why not at least get some help?
A project fork doesn’t always have to be a bad thing, either. The distributed way the Linux kernel is developed these days is basically a continual process of forking and merging. It allows for a lot of freedom to play around without disrupting the mainline.
August 3rd, 2009 at 10:48 pm
Blah blah blah. Let’s knock Microsoft.
It’s no different from any other open source project. They don’t want contributions, so what? You can get the code and modify it and use it how you want.
Sounds to me like you want a patch but can’t be bothered to do it yourself so you want other people to do it for you. For free.
That’s. Not. What. Free. Software. Is. All. About.
August 3rd, 2009 at 10:50 pm
Yeah, i’m all about free-loading… do some reading before jumping to conclusions
August 4th, 2009 at 1:47 am
Davy, don’t feed the trolls
Let them go mate, they’re not worth it.
I guess the kicker here is that a large portion (if not the whole portion) of MS projects on CodePlex aren’t actually Open Source. They’re more “shared source”. They’re released on CodePlex so that they don’t have to be in sync with the .NET framework’s release cycle (which is bloody huuuuuuge) and hence can release more frequently. This is similar to a lot of other projects outside of MS. Submitting patches might not be allowed officially, but behind the scenes you never know they might take your code and include it in the next release. But as you said, there’s no guarantee.
It might be worth you while to try plugging the code you need into Windsor, or as Jonathon said, give Autofac a spin?
Cheers.
August 4th, 2009 at 11:31 am
[...] This Is Why I Don’t Like Microsoft’s Way Of Open Source Development – Davy Brion talks about his dislike of the way that Microsoft are doing the Open Source development of products like the Unity Container, with sporadic check ins and releases, and not accepting community patches. [...]
August 4th, 2009 at 12:44 pm
So what you want is Microsoft Accept Patches from you and zillions others and decide whether it’s high-quality or not, if they are high quality, include it ? Whose going to pay for the time this(Process of judging) takes?
This is a nice way to get blog exposure, bash Microsoft in some way and then get listed in top blogs.
Try posting your high-quality patches to any other Open-Source project. No one has time to judge and test whether your quality is “high” or not!
August 4th, 2009 at 1:58 pm
“So let’s see… i can request a feature, but there’s no guarantee that it will be implemented”
So explain to me why you think I didn’t read first?
August 4th, 2009 at 2:00 pm
@Jim
requesting a feature is _the only reasonable_ thing you can do because you can’t contribute it _to_ the project. it has absolutely nothing to do with wanting something done by someone else for free.
you may have read first, but you definitely didn’t understand
August 4th, 2009 at 2:31 pm
The opinions expressed by the pro-microsoft crowd on this post are the reason I gave up learning to develop for .Net. Between the general passive-aggressive defensiveness and astroturfing it’s kind of hard to find the plain practical and useful comments. I got tired of the Apple crowd for the same reasons, and have finally discovered that it’s only the semi-open languages, like Python, Ruby and Java where the signal to noise ratio is a bit better, it seems to me.
August 4th, 2009 at 4:07 pm
[...] This Is Why I Don’t Like Microsoft’s Way Of Open Source Development | The Inquisitive Coder – … "So let’s see… i can request a feature, but there’s no guarantee that it will be implemented. Even if it were implemented, i’d have no way of using it until they decide to bless us with another code drop. I also have no way of providing the feature myself and contributing it to the project, unless i keep it privately and keep maintaining it for every new version they release. I don’t care what license they put on it, but you really can’t call this Open Source development." (tags: opensource microsoft programming copyright) [...]
August 5th, 2009 at 2:39 pm
“Trying to walk that thin line between intelligence and ignorance”… looks like you may have strayed a little bit to the wrong side here. These practices seem no different than many other open source projects. It seems you have an agenda. Just DIY.
August 5th, 2009 at 6:04 pm
Having developed in C++ for a while (and MFC being quite useless except for quick gui stuff) me, and the companies I worked for have relied heavily on open source projects for anything from xml-parsing to winsock communication. Most of the time I was in favour of the DIY approach but the company chose the open-source solution. Mainly because of the excellent support, the ability to ask for features, and the possibility to submit patches. And yes I have known a couple of them to be accepted.
A quick google shows that the author of this post has contributed to one or two open-source projects himself so I think he’s in a good position to pass judgement on the MS way of working.
@Jim Danby
They don’t want contributions, so what? You can get the code and modify it and use it how you want.
That’s. Not. What. Open. Source. Is. All. About.
@Dinesh Gajjar
Using a disassembler to go through to some of the MS dotnet dll’s, or opening the WINSDK files (for the C++ guys) and comparing it to the code I have downloaded from this site, I reckon it would take a monkey about three seconds to verify that the quality of the code meets or surpasses that of the existing codebase.
@J Abits
Just DIY … Unbelievable response, but much in the MS tradition. I remember a KB suggesting that for fixing a bug in the MFC dll’s, they advised changing the code and recompiling it. Some people actually followed this advise, with deployment hell following right after that, two versions of the MSVCRT.dll deployed in one environment… happy (clsid) hunting.
At all of the above :
One of the things I really liked about this blog when it started was the absence of ignorant insults, and whenever a controversial opinion was on display, people discussed in a passionate but respectfull way. You don’t have to agree, as I don’t, with everything that’s said, but if all you can contribute is of such a low quality it seems to me that you guys are the one looking for exposure by posting meaningless comments on an otherwise very interesting blog.
August 5th, 2009 at 8:52 pm
“requesting a feature is _the only reasonable_ thing you can do because you can’t contribute it _to_ the project”
Well no. You can write the feature yourself and release it to the community if you want to. It may not be ideal but it is no different to many other open source projects.
One question: Did you actually request a feature or just assume that you would not get what you want because you are dealing with Microsoft? I have worked with Microsoft on some projects and found them very open to suggestions.
I really don’t understand the problem here and I am not just pro-Microsoft. I work with many platforms and Silverlight happens to be one of them. Maybe I am misreading your prose (as others must also be) but you sound aggressive and anti-Microsoft, rather that providing an informed argument.
I would be interested to see a follow up post explaining exactly what happened when you actually contacted the team with a polite suggestion. I’d particularly like to see what their response would be.
August 5th, 2009 at 9:04 pm
http://unity.codeplex.com/WorkItem/View.aspx?WorkItemId=1989
it was already requested on April 9, 2008
August 6th, 2009 at 12:07 am
Davy,
This is on the product backlog for EntLib 5.0 (published in April).
896 24 U03: Support for passing arguments to the Resolve method (M)
Rumour has it people in the next room from me are working on it right now.
Ade Miller
Development Manager, Microsoft patterns & practices
August 6th, 2009 at 7:03 am
@Ade
great, but is there any reason why this information is not available on the project’s issue tracker on codeplex?
August 8th, 2009 at 4:07 am
Davy,
This is an artifact/limitation of the way we develop projects like EntLib. We’re currently considering how we could do better with some of the things you mention in your original post.
The EntLib team have been through and updated the active EntLib/Unity issues so it’s clear which ones are being worked on for v5. We’ll be working on being more proactive in doing this for future projects and releases.
Ade
August 10th, 2009 at 8:12 pm
As Ade Miller’s comments show, I think that one thing to take away from this discussion is that there’s not really a single Microsoft “Way Of Open Source Development”. MS is a very large entity, there will be some projects that are just periodic dumps of the MS internal code base with no interaction with outside users, and there will be some projects that have an active commnuity outside of Microsoft (Wix for example). Similarly, there are non-MS projects that are very restrictive of who’s patches they will consider, and other projects that are much more accepting of outside contributions. I remember when GCC was forked into ECGS because some people thought that the GCC maintainers were too restrictive/slow moving (ECGS has since been folded back into GCC – actually, I think it’s more like GCC picked up ECGS as its new code base).