2. Knowing the customer
One of the problems associated with MIT Kerberos in particular, is our license is so permissive that organizations can download and use our code, and we never have to know who they are or how they are using it. Some might see this as a “feature”, but I see it as a bug. I want to know who our customers are! Otherwise, how can we ask what they need in terms of new features or functionality in order to make our product more useful?
Of course, we knew many of the major players already. We have had close working relationships with Apple, Debian, Red Hat and Sun for many years. What was surprising, was how many other interesting uses people were finding for MIT Kerberos.
When the buzz about the launch of the Consortium got into the press, lots of organizations started identifying themselves as using our code in their products. Centrify and TeamF1 were two of the first organizations to step forward and join the Consortium. Centrify uses MIT Kerberos to integrate most platforms around Active Directory. Team F1 puts Kerberos on embedded devices for OEMs.
Many of our other customers were discovered by what I’ll call “benevolent stalking”. I always thought it was interesting that lots of the same people were answering very sophisticated questions on the krbdev list using nondescript email accounts, and also contributing patches to our RT system. A few friendly introductory emails to some of these individuals yielded replies from four of the very large banks, where Kerberos was their primary authentication mechanism. This was great news, because now we were in touch with some of very large organizational customers for the first time.
So we organized several conference calls with these companies last year as we were planning the feature set for our 1.7 release. To our surprise, one of the banks was using a fairly old version of our code. This was odd, and several members of our team worried that they had not upgraded due to concerns about the security of our more recent releases. So we asked why they had not upgraded. The answer was simple: they had a modified version of MIT Kerberos with features they depended on, and there wasn’t much in the more recent releases that made an upgrade worth the considerable cost!
This was information we needed to hear. So the subject immediately turned to one of what features would make an upgrade worth the cost. We immediately identified two features that the bank depended on and put them on the work schedule for our 1.7 release. We also asked many other organizations what features they would like to see, and soon patterns began emerging around a specific set of features that customers wanted. So when we delivered Kerberos 1.7 this past June, for the very first time the features and improvements that went into it were based on what a large number of our customers actually said they wanted.
The 1.8 release features are being driven by the same process of asking customers what features they need most. For example, we heard loud and clear that there was a need for a password lockout feature in MIT Kerberos. We think the 1.8 release will be well received when it is released in Spring 2010.
3. Documentation
4. Database support
5. Better coding practices
6. A good test suite
7. Kerberos for Mobile
8. Release Kerberos 1.7
9. Simpler revenue model
10. Community Building