The bounty did not play into the decision to refactor the authentication system. We have had the AD auth provider for a couple of years now, but because of the way it was tied into the system, it made it difficult for the AD team to make changes without also needing to coordinate those changes with the developers working on the core. Independent of feature requests from the community, the management team also identifies what we believe are important enhancements that address concerns by stakeholders which are not really represented in the forums or who do not post to the roadmap module. During the MVP summit this spring we identified the authentication system as one area that should be refactored to allow the AD team to work independently moving forward. We also recognized that this would also benefit users who wanted to use OpenID, MS Passport, LDAP or any other authentication system since there would be a clean method available for integrating those systems into DNN.
Around the time of the MVP summit we were approached by Dan Bartholomew about donating his module for CardSpace support to DotNetNuke. We felt that this was a good enhancement and an opportunity to help define requirements for the auth system refactoring. One thing that we have learned over the last several years is that whenever designing a "pluggable" extension point, that it is always a good idea to have several different concrete implementations of the plugin API. This allows you to validate your design and ensure that you will be able to accomodate a wide variety of plugins. In this case it was crucial to the re-design effort since the DNN, AD and CardSpace methods of authentication are so different that it forced us to really think through the design.
Prior to the MVP summit, I had blogged about us looking at OpenID as a potential authentication provider for DotNetNuke. As part of my investigation I became involved with the DotNetOpenID project as one of the founding members. When we started refactoring the authentication system, our plan was to not include OpenID. It did not appear to have much support beyond a few sites. Since that initial decision, Microsoft, Sun and AOL signed on to work with the OpenID committee to enable support from their various platforms. We also saw that other CMSs like Drupal and Plone were also working on implementations. Charles already had the basic DNN, AD and Cardspace refactorings complete. At this point we decided to go ahead and implement OpenID. Given all of the other provider work that had already been done, Charles was able to add OpenID support in just a day or so. At this point we were in contact with some of the members of the OpenID committee who suggested that we should apply for the bounty. Further research indicated that we would need to update the DotNetOpenID library to support the OpenID 2.0 spec (we had only implemented v1.1 in the initial port) in order to be eligible for the bounty. I spent 1 day working on the OpenID library to add basic 2.0 support. Our efforts in adding an OpenID provider were sufficient for the OpenID committee to award us, along with Drupal and Plone, with the bounties at OSCON 2007. So while the bounty affected our decision to work on the OpenID 2.0 support it did not impact whether or not we implemented OpenID.
One thing that we have always been clear about is that there are many factors that go into our decision to implement a given feature. Community requests are one factor, sponsored development is another, and our own personal experiences as maintainers of the software is another. Finally we have to factor in the complexity of the change, how long it will take to implement the change and how risky that change might be with respect to impacting existing installations. Workflow is a great example of a feature, that while it is highly desired by both the community and core team members, requires a much larger development effort and which is very risky since it will impact almost every part of the core to fully implement. This type of change requires much more due dilligence before we implement it since we will have to live with our implementation for a long time. As we have spoken with a number of different stakeholders and potential sponsors for this feature we have found that different individuals have different requirements and ideas about what constitutes Workflow. Some think a simple remote publishing feature is all that is required. Some desire a two step approval process for content changes and are ok if this occurs on the live site. Still others desire a full blown approval chain, with rollback and versioning support for all changes, both content and configuration. As you can see, this is not a trivial item, which means that we have delayed implementing the feature.