So I spent some time last week at the Enterprise Open Source conference in New York City. It was a high profile event which attracted some of the largest, most successful open source projects in the world ( JBOSS, Eclipse, SugarCRM, etc... ). I found the conference very interesting as it had a couple significant themes which were very applicable to the DotNetNuke project. The first theme was the acceptance and use of open source solution by Enterprise vendors. The second theme was open source business models. So let me provide some detail...
In terms of enterprise acceptance I learned a few things which I found rather interesting. The only platforms which enterprise vendors consider worthy of supporting their organizations are J2EE and .NET. Since LAMP projects have become so popular lately I had assumed that this stack has finally achieved acceptance at this level - but apparently not. LAMP is still a medium to small business solution mainly because of scalability and security issues. And since this was an open source conference there was very little mention of .NET in any of the presentations - but in talking with attendees it became clear that their clients recognized the benefits of the .NET platform and in many cases were choosing it over a J2EE alternative. In addition, I found out that nobody had the slightest clue that there were open source projects available for .NET. So maybe on the surface ".NET open source" does sound like an oxymoron to these people - but I got the impression that there was a great deal of interest once I made them aware.
In terms of open source business models, it was interesting to hear the experience of other large projects. The reality is DotNetNuke is leveraging the exact same techniques as other open source projects to produce a professional result. Some of these projects have received significant funding through VC channels to help them get started or grow more rapidly but in terms of basic revenue strategies, there are some standard models which most projects are following.
A common thread in the talk about business models was related to how open source projects are managed. In all cases there are 2 different types of project resources working towards a common goal. The first type of resource is the type which most people think of when they hear "open source" - the volunteers. Volunteers are an extremely valuable resource for specific project tasks ( ie. identifying requirements, testing functionality, fixing bugs, etc... ). Volunteers contribute varying amounts of time/effort and bring different skill sets to the table - all of which benefit the project. However no organization can be solely comprised of volunteers. This is because volunteers need guidance to understand the goals they are working topwards. Which brings up the second type of resource. A dedicated set of committed resources are responsible for the ongoing management of the project. And we are not just talking about management of the software development activities but rather the other critical aspects of a product such as intellectual property, licensing, marketing, community programs, etc... And as you would expect, these resources are full-time - which requires revenue to support them. So when we look at open source business models, we see most projects introduce revenue generating activities so that the dedicated resources can be sustained. Without the proper balance of both types of resources, an open source project will fail.
An interesting phenomenon which I noticed in the discussions relating to open source business models was that, like any ecosystem, higher benefits are provided to those who provide scarcer resources. Most people only consider the standard "meritocracy" when they think about this concept - for example a veteran developer will get more recognition than a user who posts their opinions in the public forums. However there is another side to this as well. Since revenue is the scarcest resource of all in an open source project, members who contribute financially to the project often receive the highest benefits. Now some people could argue that this paradigm is not fair or does not align with true open source ideology. But the reality is that revenue is required to support dedicated resources and there needs to be some way to encourage contributions.
So lets put this into perspective. During the 6 month DotNetNuke 3.3/4.3 development cycle there was approximately 2000 hours of billable full-time effort which was invested into development of the product. When I say "billable", I mean time which members of the development team were directly compensated for. Large scale features such as the Membership, Role, Profile which take multiple full-time months to complete can not realistically be accomplished by volunteers ( unless the community is prepared to wait years between releases rather than months ). So you could do the math yourself to determine the direct project cost. If you used standard consulting rates you would arrive at a figure of anywhere from $100,000 for off-shore development to $250,000 for on-shore development. Then you can factor in the total time invested by our volunteer resources as well ( not compensated ) which I would estimate to be at least the same level - if not more ( considering we have 15+ core volunteers ).
And this is no different than any other DotNetNuke release over the past 3 years ( which I am sure is a total shock to some people ). There has always been a few full-time resources who have been paid to implement significant enhancements within the product. And the end result is that thousands of organization have not needed to individually fund enhancements at this level of magnitude. Instead, they reap the rewards of the work being done once and then shared with the entire community. But where does this revenue come from you ask? Well, it has not been easy. Since the general mindset is that open source work is done for free, revenue is often hard to come by. So in the early stages I subsidized the project by reinvesting the margins on private consulting work. Then banner advertising revenue began to improve. But the number of dedicated resources we could support was still minimal.
So this is one of the main reasons we launched the Benefactor Program in December 2005. If it was not for the Benefactor Program and some timely Sponsored Development contracts, DotNetNuke 3.3/4.3 would have likely been delayed for many more months. What people need to realize is the power of large communities. Having many community members opt into the Benefactor program has the same financial effect to DotNetNuke as a single organization making a substantial donation ( which is very difficult to accept anyways without comprimising the objectivity of the project ). Anyways, it sounds like I am making a sales pitch here - which is not my intention at all - I just thought it may be useful to provide some transparency on the inner workings of open source projects so that the community better understands how they really operate ( all myths aside ).