Opening the Development Process
MIT Kerberos has largely been developed by a small group of people at any one time. We accept code from outside sources like Sun, Novell and the University of Michigan. However we spend a lot of time making that code fit our standards and design constraints. Few people outside of MIT are involved in setting policy or focusing on the overall architecture of the product beyond the few projects they care about. This needs to change.
At the same time as we were putting together the consortium launch last week, several members of the core team were meeting to discuss how we work with outside contributors. First, it’s clear that we need to get some. We need to interest people outside of MIT in dedicating significant time to working on MIT Kerberos and to caring about the product as a whole rather than just one subsystem or feature. Part of doing this will be offering these people real influence and the ability not to block on MIT to get their work done.
We need to work on opening our processes and establishing clear policies and procedures for decision making. Over the next few weeks I hope to be presenting proposed policies for review. We also need to work on opening up our description of what projects are being worked on and on release processes. MIT and the consortium will control what priorities our staff focus on, but the rest of the community needs to be able to review how we plan to accomplish these tasks and work on tasks of their own.
We came to a few basic decisions at the meetings. First, MIT is not a special customer of MIT Kerberos. We will design a product that is right for all our users. MIT is a customer; we will try to make MIT happy but not at the expense of our other users. We also decided that we need to be careful to make projects available for public review and make sure that projects receive positive support before they are implemented.
November 9th, 2007 at 1:16 pm
Hi!
I have a thought about general future direction for Kerberos and I’d like to share it. IMO Kerberos protocol should be merged into LDAP protocol (using LDAP extended operations or even devising a new revision of the LDAP protocol itself).
Currently lots of people get confused by the separation of those two, and use them improperly (e.g. the widespread use of LDAP for authentication using LDAP simple bind operation).
The present implementations should also be to blame – it’s quite complex to e.g. get OpenLDAP and MIT Kerberos to work together, while there should be a solution that practically works out of the box.
You can read my detailed thoughts on this subject on my blog:
http://olo.org.pl/dr/node/27