I haven’t really found the time to test OpenWrap thoroughly, but knowing the thrills and pangs one get on setting up a package management system for .NET, I immediately acknowledged the importance of this project. Sure, there are other cool alternatives being developed right now such as Bricks and WebGAC; you can even set up Ivy to play nice with .NET, as we’ve successfully done at Locaweb. But regarding the emergence of competitive solutions for package management in the .NET ecosystem, Sebastien couldn’t put it a better way:

(…) Package management is going to be the next Vietnam war on .net, and many people will come up with different solutions. It’s all for the best, and most projects, as they have done many times before, will die off on their own. This is to be expected. As such, I implore the .net world to let enough time for each of those projects to compete purely on the quality and functionality they provide, and let the best one eliminate naturally the other ones. Don’t succumb to the belief that standardizing early will help, or that popularity would be a distinctive factor. If we fuck-up the package management story on .net, we may never recover, so give it a bit of time and be circumspect in your analysis.

That being said, this post aims only at showing what’s out there regarding package management, with a special emphasis on OpenWrap. Sebastien has been posting several articles on his blog about how the project is developing, so it should be interesting to watch his progress. Last but not least, it is an open-source project, so feedback/contribution from the community should be more than welcome.

The lectures are anywhere between 30 to 60 minutes each and are based on the Haskell language–for which Meijer has special feelings. He even goes as far as leaving one or two homework assignments at the end of each session, which often involve comparing C# to Haskell and fiddling around with the latter.

• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 4
• Chapter 5
• Chapter 6
• Chapter 7
• Chapter 8
• Chapter 9
• Chapter 10
• Chapter 11
• Chapter 12
• Chapter 13

This is truly a “Can’t Miss” and I recommend it to anyone who wants to learn more about the origins of functional programming and how it works. As a bonus, you even end-up learning Haskell… “YOU KNOW!” lol

* * *

This is the first installment of a series of micro-posts about things I happen to stumble upon on the Internet and which should be of interest to people. If you like it, follow the “Can’t Miss” category to get updates.

I’ve been working – both academically and professionally – with the .NET stack since 2003 and although I didn’t meet the rough edges of .NET 1.0 and Visual Studio 2002, I did saw the steep transition from Framework 1.1 to 2.0 and the smoother 3.0 and 3.5 steps. Right now we’re once again in a period of transition which seems to stale the .NET world for a couple of months at every release cycle. It seems the world is waiting for .NET 4.0 and whatever wasn’t good enough on the previous version–such as the Entity Framework–is not going to be further developed by the community. While in theory this represents a golden opportunity for alternative libraries to gain some momentum, in practice corporate developers do realize that the cost of changing legacy applications they simply don’t want to touch outweighs the cost of sitting still while Microsoft puts the latest bells and whistles to the “branded” library and the mainstream community starts blogging with some useful prototypes people can reproduce.

That said, what seems to be wrong? Well, for starters, it is important to point out that the Microsoft ecosystem, while extremely diverse and rich, could be said to have roughly two kinds of developers: those who by and large are using exclusively the System.* and Microsoft.* namespaces, and dragging-and-dropping like crazy; and those who are producing more exotic code by relying on third-party–free and commercial–libraries. The latter will necessarily be coming from or occasionally wandering off to a non-Microsoft platform. Additionally, if you think in terms of the Dreyfus model, you’ll most likely find more individuals with ‘proficient’ or ‘expert’ skill levels among the group not relying solely on the Microsoft stack. Microsoft has come a long-way in order to provide to such a heterogeneous community and for that it had to make compromises: shall always be agnostic; shall never be opinionated; will always feel like a duck–can’t seem to fly, swim nor walk properly, but does it all.

At the end of the day, what’s the product of this policy? Pulverization, it seems. If you look at what the community has produced to specialize the loose ends Microsoft left in its framework, you’ll find a mess. A mess of great code, but a mess nevertheless. While Ayende Rahien, Jeff Brown, Jimmy Nilsson, Miguel de Icaza and others may be strong voices on the community, it doesn’t feel like they’ve ever sat down and met each other. But why should they? Has Microsoft set an example in the first place? One thing is for certain: if the community has grown up like that, it has only done so because it was following Microsoft’s steps. There are many areas where it’s easy to see overlapping bits in the framework where you don’t feel collaboration and reuse took place: Linq to SQL vs. Entity Framework, PLINQ vs. CCR, ASP.NET vs. ASP.NET MVC, WCF vs. ASP.NET MVC . . . the list goes on. None of the elements of each pair are exactly like the other (and it was never intended that they should), but I guarantee you’ll find repeated functionality. The point is: if Microsoft is repeating itself and some of its many areas are evolving at some extent unaware of their neighbor’s progress, why shouldn’t the community? Hey, why reuse if we can come up with a new wheel, right? Well, wrong . . .

The very community Microsoft fed and raised could be what is holding .NET back today. And if that is so, then Microsoft itself is to blame. While it’s useless to compare the .NET community to others, I’m sure that it wouldn’t hurt if we had the Java maturity and scope or the RoR openness. Instead, what we have is some great software being produced by individuals who sadly can’t embrace the whole world, some great software being produced by companies, but which stay proprietary (and will remain so because it cost them a lot of money to develop and because, to put it simply, they’re just too damn afraid of open-source), and no cohesion whatsoever. (The reason universities aren’t producing more with the Microsoft stack despite their aggressive programs such as DreamSpark, ImagineCup and MSDNAA is beyond me. Maybe the company is simply trying too hard to fit in.) Meanwhile, Microsoft’s policy has been (up until now, read along) of watching what’s a must-have in the community and either bringing it in or recreating it (ORM, IoC and logging comes to mind). Kind of a crazy self-embrace-and-destroy-ish strategy.

Folks like Scott Guthrie and Erik Meijer, however, have been pushing a different agenda. They and their colleagues (Hanselman, Haack, Block etc.) have realized that Microsoft hasn’t been leading the evolution of this industry for some time and that the grass on the other side could indeed be greener. Microsoft has a lot to teach and certainly has a lot to learn, and those guys were the ones who step up and started making a difference. This is a generation of bloggers, start-ups and self-management models, and where accountability and transparency are prime values. Microsoft, I think, has caught up with that, a sign that the times have changed and that Ozzie is indeed continuing where Gates left off, taking the company into the future. The important thing is that the industry, as whole, ends up better at the end of the day.

Microsoft has to keep in that track. Opening ASP.NET MVC, embracing jQuery and the Mono Project, for example, were great moves and, not surprisingly, they came on Guthrie’s watch. While Microsoft has made some design decisions for the developers–and make no mistake: some of them, namely the agnostic die-hards, won’t like these decisions–they’ve reached a tipping point in the history of the ecosystem. Microsoft’s somewhat controversial new endeavor, CodePlex Foundation, is rapidly gaining popularity and will be subject of a lot of scrutiny by the community in the next months. What has changed in the strategy, is that instead of messing around with what the community has produced, Microsoft is indirectly providing guidance (with processes, techniques, legal mechanisms etc.) for commercial and open-source developers to lift themselves (and their work) up by their own bootstraps. As reported by Jon Tørresdal at InfoQ, Scott Bellware explains:

Microsoft has been forced to build new products from scratch to provide Microsoft customers with the value that open source projects have proven and delivered. These projects are often far less robust and mature as the open source that inspired them. The protections offered by the CodePlex foundation are also a turning point that frees up Microsoft resources to focus on integrating existing value rather than duplicating it, and risk missing the value targets offered already by open source.

All of this points to an evolving shift in culture and values toward the freedom to choose solutions based on merit rather than mere intellectual property risk mitigation.

This shift in culture and values toward meritocracy and the benefits that come from open competition that stands a chance of taking Microsoft and Microsoft customer community in a brand new directions that can provide more value from the Microsoft stack than we’ve seen yet.

When collaboration and cooperation start taking place (hey, isn’t it high time people started seeing value on using distributed-VCS?), projects can evolve naturally and in an orderly fashion. No reason why it should be different from what’s already been happening for ages in the unix-like open-source front. In the future, there’s a great chance we’ll see things like a package manager for libraries, common repositories, self-organizing and integrated communities, and flourishing projects. In the end, my take is that, under this strategy, Microsoft’s ecosystems grows stronger, gains market share, and all that without compromising the company’s business model.

* * *

This blog is about technology, business administration and engineering. I’ll be watching how the Microsoft ecosystem evolves from here on and I hope to be writing again soon about some predictions I guessed right. Meanwhile, I’ll focus on how to create great software by mashing .NET stuff up, I’ll be visiting different platforms either by professional necessity or by sheer curiosity (the latter more often than the former), and I’ll occasionally be visiting topics on business models and human relations. That’s sharpshooting.