Great thread guys! I REALLY like the divergence of interest and opinion here and wonder if our task might be simpler if, following Torben, we write different mission statements for our different audiences and constituencies (say, three), if each had a short and long version, and if we kept in mind their purpose, as I understand it: inviting people (including ourselves) to join the enterprise. That is, as Caroline describes nicely, the technology is tied to a community and a business model. When discussing .lrn to a propective university person two weeks ago, I quickly wished I had a list of talking points that went beyond the feature list to what getting involved with this technology and community might be about. For instance, I get the impression that an open source solution works well in a university setting where the administration respects and supports a strong in-house developer team and that it works less well with those who want to out-source everything, buy a one-size-for-all solution, and prefer to pay more for a license than pay less to support their own people. That is, with Dotlrn I don't get to call a help desk and demand an answer in 24 hours, but instead, must be far more resourceful, including, rtfm, making sure the people around me want to help me as I try to help them, cultivating friendships in our community, learning how to write forum postings that might get answers, taking on clients willing to be flexible, etc. I think the strength of my understanding and implementation has been greatly improved because of it. Thus, I think the peculiar features of the developer community and business model are of one piece with the technology, and so I'd think it best to write one mission statement for the dotlrn group, another for the non-profits, and so forth, and each based on an honest appraisal of the what is needed to make it work and the qualitative benefits of solving the problem this way.
