The last 7 years has been a very exciting time for the DotNetNuke team. This period has been marked by constant change. Sometimes the changes were positive and helped move the project forward, and other times the changes did not achieve the desired results and thus became a learning opportunity. During this period we have had almost 80 core team members and project leads, had 5 major releases, hosted the project on 3 different open source websites, had 3 different project forums, and used 3 different source code management systems (hat tip to the reader who can name the websites and SCMs) . We have also launched a company, created a commercial version of the project, and hosted conferences in North America and Europe. All in all, it has been a pretty busy time, marked by lots of changes. There have been 3 constants throughout the life of the project – Shaun Walker has always been the leader of the project, DotNetNuke has always been offered under a BSD open source license (we’ll conveniently ignore Shaun’s brief flirtation with a different license in 2003), and we have always operated a closed repository. Today I am happy to announce that one of those is changing.
Every Open Source Software project has a lot of decisions to make concerning how they operate: what organizational structure to use, what technology to use, and how open do they want to be. I don’t believe there is any right or wrong answer for any of these decisions. Some projects adopt a very flat organizational structure where all project members have an equal say in the project decisions. Other projects follow a more traditional hierarchical structure. Projects also have a wide variety of technology they use and support. Whether PHP, Java or .Net, they all address some need by a specific segment of the development community. Lastly, a fundamental decision faced by each Open Source project, is that the project team must also choose how open they wish to be. The open source license is just one aspect of that openness. Some projects have almost all discussions in public, others are more reserved and private. Some projects open their entire repository for public scrutiny and others only provide an occasional snapshot of their source code. I even know of one project that opened up their CI server (that is a little too open for my taste). It would be easy for me to criticize another project’s decisions, but I know that as an outsider I have little insight or knowledge as to why a project made the decisions they did. I am just happy that projects choose an Open Source model at all, even if I may not agree or understand every decision made by the project’s leaders. I view any openness and transparency as a good thing which should be encouraged.
From the very beginning the project has adopted the policy that we would release source code, when we had a release that we were happy with. We have tried to release on a fairly frequent basis once the code has been stabilized and tested. This policy has minimized some noise and distractions that can occur when you have an almost infinite number of versions to support. This policy has not always been popular with some segments of the community, but I think our track record shows that you can build a highly successful project following this model. One of the downsides of this policy is that we often don’t find bugs until later in the development cycle. While this has posed challenges for the project, we felt that the benefits of a more controlled release process outweighed the negatives.
About 18 months ago, we started looking at opening up our repository. There were a number of challenges that needed to be addressed to make this happen. We have been using SourceGear Vault and Fortress for the past 6 years on the project for our SCM tool. These are good products which have served us well and we didn’t want to be forced to move to another SCM tool in order to make this transition. We have looked at a number of options but never found anything that we were really comfortable using on a day to day basis. It seemed like any choice we made was going to incur a huge learning curve and cause a lot of disruption with the project as we moved to a new repository. Finding a solution which met all of our requirements was a big challenge.
We currently use the same tools to manage both the Open Source and commercial versions of the project. For obvious reasons, we wanted to be able to keep our internal work private without requiring us to maintain 2 different SCMs – one for the Open Source project and another for our internal tools and commercial offering. In addition to the work we do for our Professional product, we also felt that we needed a private work area for new features which are under development. Often new features are incomplete and won’t work for several weeks while they are in development. It is also possible that a feature may not make a particular release window in which case we will hold it until our next major release. Any solution we adopted had to allow us to maintain both a public repository and a private repository without requiring our developers to use 2 different SCMs.
We also needed a solution which would work well in the Open Source space. Users should be able to use freely available tools to access the repository. Visual Studio Team Foundation Server was one option, but realistically, most users would not have access to the tools to checkout code. It would have also required us to shift completely over to TFS to meet our first requirement of maintaining a single tool for all of our SCM needs. This was certainly a possibility, but came with a number of challenges. The second option was to move to a solution like SVN. SVN is widely used in the Open Source community, but again would require a major commitment from the project to learn this new SCM tool.
The final issue came down to resource availability. We needed to have some free time to actually effect the change we desired. In this end, this is the issue which caused us the most problems. Because the repository affects both the Open Source project as well as the commercial product we needed to free up some corporate resources to handle the migration effort and maintenance of the repository moving forward. If we hosted the repository ourselves, it meant that we would need our IT staff to come up to speed on yet one more piece of server software. As I have noted recently, DotNetNuke Corporation has been busy hiring additional staff this year. We have been very successful with our DotNetNuke Professional product which has allowed us to hire the staff we needed to handle issues like this one.
In the end, we have decided to stick with SourceGear Fortress – for now. It has served us well for the last 6 years and we didn’t want to be forced to change for this one reason. We also decided that for those people who like TFS and have the tools, that they should be able to use their tool of choice. Finally, we think that SVN support is also important for many users in the Open Source community. It has pretty much become the de-facto standard in the Open Source world. Sites like Ohloh and Koders have native support for SVN and provide nice tools for investigating Open Source code.
Internally, the project will continue to use the same Fortress repository we have been using. There will be no immediate impact to our project team. As we make changes in our main trunk, we will push those changes to the DotNetNuke project page on CodePlex. Since CodePlex supports both TFS and SVN access, users are free to use whatever client tool they prefer. Initially, the changes will be pushed to CodePlex manually while we finish tweaking our automation code. Once those tweaks are complete we will incorporate the synchronization as part of our CI process so that it happens automatically whenever someone checks in a change to the project. We hope to have the automation completed in the next couple of weeks.
One of the added benefits of this approach is that it allows us to offer a single location for downloading DotNetNuke. Whether you want the packaged releases or the most up to date code, you can go to one spot. This solution also insulates the community from any internal changes we may make regarding our SCM tool. We have been investigating TFS recently and are very excited about some of the changes coming in VS2010 but we felt it was important to decouple these two decisions. This allows us to make a transition when the project is ready and to do so without impacting the community’s access to the code repository.
I am happy that we are finally able to offer this benefit to the community. It is something we have wanted to do for a while and it is gratifying to finally be able to make it a reality. One word of warning though. Just remember that the code in the repository has not been fully tested. It will likely compile (although the build will occasionally break when someone forgets to check in all of their code changes), but the code in the repository has not been through our internal QA process and therefore will not be as stable as our normal releases. Use it at your own risk. We have other initiatives we are working on to help improve the code quality when it is checked in, but those will take a while to get fully implemented.
Technorati Tags: DotNetNuke,CodePlex,Open Source