Back in September, we did something with Orchard that is kind of a big deal: we transferred control over the Orchard project to the community.

Most Open Source projects that were initiated by corporations such as Microsoft are nowadays still governed by that corporation. They may have an open license, they may take patches and contributions, they may have given the copyright to some non-profit foundation, but for all practical purposes, it’s still that corporation that controls the project and makes the big decisions.

That wasn’t what we wanted for Orchard. We wanted to trust the community completely to do what’s best for the project. This is why we organized elections for our new Steering Committee and had five members elected. Anyone who had ever posted anything on our forums that wasn’t spam could be a candidate, and had five votes to cast.

We got 9 candidates, and after a week of vote casting, we had our committee elected (see http://orchard.codeplex.com/discussions/271355 for the details of the vote). Our five members are elected for a year and they each get a vote in any major decision. Two out of those five are Microsoft employees, which means the company doesn’t even have a majority (even though I have a veto right that I never used, as the elected “benevolent dictator” of the group). We have public online meetings every week.

The committee’s role is to give the project’s strategic direction, and to decide what feature areas are going to be in the next releases. It is not to make technical decisions or build the product (more on that in a moment). The weekly meetings are used to give status on current development, do bug triage and make decisions as needed.

This was not just the right thing to do. It did have a very visible impact on the involvement of non-Microsoft developers. Shortly after the election, we started calling for teams to form around our 1.4 release’s features. Feature teams are being given a feature scope by the committee, and they are then free to make their own decisions on technical design. They regularly interact with the committee, which gets to decide when the features make it into the main branch.

This was quite successful as we are preparing to launch what will be the first release of Orchard where entire features have been written by the community. In fact, 3 out of 4 of the new feature areas of 1.4 have been written mostly by non-Microsoft developers.

To my knowledge, this makes Orchard the most open of all Microsoft-initiated Open Source projects. It now belongs entirely to the community, and absolutely everything is not only done publicly but also in a way where community participation is actively sought after and encouraged.

My hope is that as the project becomes more and more successful, our model gets copied by other corporate-initiated projects, at Microsoft and elsewhere. I would love to hear your thoughts, dear readers, on this.

Damn, Rob saw right through the PR lies of Phil Haack about the new NuGet gallery and figured it all out. Kidding, kidding. For your enjoyment and context, here is Rob’s post:
http://wekeroad.com/2011/12/06/nuget-and-orchard/

Phil made a thoughtful answer to the post where he gives the rationale behind the decision:
http://wekeroad.com/2011/12/06/nuget-and-orchard/#comment-380571113

What I want to address here is what that means (or not) about Orchard.

“Why wasn’t it fast before?”

Because by default, back when the NuGet gallery was first built, Orchard was grossly under optimized. We made a lot of progress, but it still is under optimized out of the box --in a number of ways-- which is why we’re having this discussion for the 1.4 release:
http://orchard.codeplex.com/discussions/274921

One thing you cannot accuse the Orchard team of is premature optimization… But seriously, there are options available today: installing the cache module, or the combinator module. Or custom, in-site optimizations.

So could the NuGet team have optimized its gallery instead of mobilizing several engineers over a few months to rewrite it? Sure they could have, but it so happened that they didn’t, for reasons Phil explained better than I could.

As a matter of facts, our own gallery site, which just passed the million-download mark, still uses that same codebase that NuGet was using before. The new NuGet gallery doesn’t display total download stats (because the home page is now static html) but I believe it’s around 3 million so we’re looking at a similar scale here. Just visit http://gallery.orchardproject.net/ and you’ll see that it’s performing quite well. So what’s the deal here?

Well, we did spend the time to apply a few optimizations:

• We profiled the code and fixed the biggest bottlenecks. Those fixes, of course, now benefit all Orchard users.
• We profiled the database queries (using Ayende’s excellent NHProf) and optimized the biggest offenders.
• We activated output caching.

All optimizations that NuGet never saw applied. And well, see for yourself, it’s not too bad. We’re not quite done, there is a whole lot more we can and will do, with what limited resources we have (hint: a lot less than NuGet).

We’re not the only ones: more and more big sites are going online with Orchard, with good performance.

But Rob also says something interesting and expresses a perception that I’ve seen many times:

“I’ve deployed Big CMS’s before as a solution for clients and every single time we decided to move away. They’re great for getting off the ground – but after a while there’s just too much friction.”

That is true of some CMS, but not all. In the case of Drupal or Orchard (not what Rob used, I checked), my own experience and that of many others is that because the content model is factored at precisely the right level of abstraction, it’s actually sometimes harder to get off the ground, but the friction diminishes over time. Where a more traditional application requires you to pile functionality on a relatively monolithic data model, modern CMS allow you to add functionality in a completely decoupled and unobtrusive way that puts the composition exactly where it needs to happen, somewhere between individual properties and full types.