In one of the comments on "Should Microsoft Financially Support Open Source", a reader asked if I would grade past and current efforts at keeping DotNetNuke fiscally sound. I will try to answer that here, bearing in mind that this is only my perspective and may not match up completely with reality for PMI. I will be developing this over a six part series.
In part one, I laid out the 5 areas where I feel a project should grade themselves to see how fiscally sound they are. The aim of the scorecard is not to see if you have enough revenue to sustain the project, but rather whether you have enough revenue to allow the project to meet the goals of the project and aid the community.
- Are you able to add critical features in a timely manner?
- Are you able to provide the necessary support?
- Are you able to build the community?
- Are you able to protect the community?
- Are you able to maintain balance in your life?
Over the coming days I will take a single question and expand upon it. And then when we have a full understanding of the ScoreCard, I will attempt to grade the DotNetNuke Project. So lets look at grading criteria number 2.
Are you able to provide the necessary support?
The first criteria focused on our ability to add features to the product. This is mainly a function of having enough development resources available (either volunteer or paid). The second grading criteria is really asking the question of whether we have all of the tools and infrastructure in place to allow for an efficient development process.
Open source projects are not much different from the software development that goes on in a typical ISV. You might have all the developers and management you need, but without the proper tools and the processes in place, you will go nowhere fast. First and foremost, does the development team have the necessary editors to aid them in developing the product. This is usually not an issue unless your product requires access to key features that are only available in the higher end commercial IDE versions. In the Java world the barrier to entry here is extremely low due to the availability of open source tools like Eclipse. In the .Net world you have the option to use the Express versions of Visual Studio or even using SharpDevelop. As long as you can confine the product so that it can be efficiently built using these readily available tools then you greatly increase the pool of developers who can assist you on the project. If however, you require some features that are only available on IDEs that have a significant cost, then you will necessarily exclude developers.
This issue recently came up on the DotNetNuke project. Ever since the Express editions of Visual Studio were released, we have made sure that you could open and compile DotNetNuke using the free Express versions. It might require you to have both the VB Express and Visual Web Developer products, but it was possible for a developer to participate without incurring the expense of having Visual Studio Professional. This has made it very simple for people to learn how to code for DotNetNuke, and eventually start contributing to the community. After ASP.Net 2.0 and Visual Studio 2005 were released, Microsoft discovered that developers were not happy with the new development and compilation model for Web projects (Web site projects or WSP). This is a model that DotNetNuke initially struggled to support. After much consultation with Microsoft, we were finally able to make the complete conversion to this model just prior to the VS 2005 launch. This model was supported in the Visual Web Developer version of the IDE which meant we were able to keep development accessible to the broadest range of developers. However, because of the trouble of converting ASP.Net apps to the new model, and because of the outcry from the developer community, Microsoft decided to develop and support an add-on that would allow you to develop web applications using the old compilation model of VS 2003 (it wasn't exactly the same, but close enough that the differences didn't matter matter much). Unfortunately this add-on was not supported in the Express editions of the Visual Studio. So now we could choose to stick with the new model, which equated with a new learning curve but wider accessibility to developers, or we could shift to the older model but loose the ability to work in Web Express.
The IDE is just one tool that is necessary for software development. A project also needs to look at their ability to track feature requests and bugs, the ability to maintain their software under source control, and to provide a method of distributing the software. Each of these items could be a huge problem: if it weren't for the advent of SourceForge and the dozen or so other code repositories that are readily available for Open Source developers. These tools are a vital part of the overall robustness of the open source movement. Without SourceForge, thousands of projects would never have been started. The existence of code repositories like SourceForge is a testament to the importance of these support functions. Given the free nature of these repositories, there is no excuse for a project not having a website, version control, bug tracking and an open distribution channel.
Just because there are free versions of these tools available does not mean that they are necessarily the right tools for your project. They do however ensure that you have something. It is possible, and even likely that as your project grows, you may eventually outgrow the tools you started with. Early on, DotNetNuke was using GotDotNet for our version control, bug tracking and private discussion forums. After a few months we found that GotDotNet was not working out well for us due to some of the limitations of the services they provided. The processes we wanted to use did not mesh well with the tools that were provided. At the time, the tools were not able to scale with our project. It became increasingly difficult to check-in/check-out files. This forced us to evaluate our alternatives. We could use one of the other repository sites (like sourceforge, which we had used previously) or move to dedicated COTS products.
DotNetNuke was growing like crazy at the time and we were able to work out a very generous sponsorship arrangement with MaximumASP. We were able to leverage our own website and the visibility of the project for some much needed server space. Until this point, Microsoft had graciously offered us some hosting space, but we had extremely limited access to monitor and run DotNetNuke.com. Now we would have more server space, more control, and in return we would offer advertising space to our new sponsor. We believe that this was a clear Win/Win and was an example of good fiscal management. We were able to leverage a DotNetNuke asset (adspace - both on the DNN site and in the DNN install) and trade it for a much more important resource for the project. I believe that this is a clear example of fiscally sound decision making on the part of the project. We knew we needed better hosting support, but also could not afford the cost of the type of support that we needed.
Once we had secured server space, we were then in a position to identify various software packages to meet our specific requirements concerning version control and bug tracking. We wanted tools that would fit our processes, rather than tools that forced us to change how we were used to working. A good example of this is version control. Version control tools generally follow one of two file locking models: The pessimistic lock (typically associated with Visual Source Safe) or the optimistic lock (typically associated with CVS). Most of the DotNetNuke team were familiar with and comfortable with the pessimistic model and were unsure of the CVS approach. We did not want to force the project team to change to suit the tool, but rather sought to find tools that would fit with how the team was used to working. Once again we were able to strike deals with SourceGear and Countersoft to meet our version control and bug tracking needs.
There are many other tools that developers use during the development lifecycle. Testing tools, documentation tools, continuous integration tools etc. In order to determine if you are being fiscally sound when it comes to providing the necessary project support, you need to ask yourself whether your tools and your infrastructure are holding your project back? Do you have the control you need? Are your tools scaling as your project grows? Is your team able to work in a manner that is most efficient for them using the processes you have established? If you answer no to any of these questions, how do you plan to correct the situation? Do you have the revenue necessary to buy your way out of the problem? Does your project have anything of value that you can use to trade for services? Or will you be stuck using tools that are not suited for your project at it's current state of development?
So now we have the basis for determining whether we are fiscally sound by asking whether we are able to provide the tools and infrastructure needed to keep our project advancing. Give your project a grade.
In the next article we will look at whether you are building your community.