Designing a New OSI

Stanford Professor David Kelley is one of those rare individuals who has successfully added a new way of thinking to Western Thought: Design Thinking. Indeed, the National Academy of Engineering recognized him for nothing less than "affecting the practice of design." I have come to have great respect for the process of design thinking that David Kelley formalized and now teaches, and now it is time to show that respect by actually practicing what is preached. Before I do, I'd like to give one other reference to the topic, and that is Bruce Nussbaum's design blog at Business Week. Here's a typical and relevant entry about Design Thinking and Innovation for Social Issues. Design Thinking is a process, and every company that does it defines that process based on some common principles. As I practice it, there are seven phases (which need not be run in any given order, but which must all, ultimately, be run):

• Define -- Define the problem to be solved
• Research -- Collect relevant data
• Ideate -- Generate (without criticism) as many ideas as possible
• Prototype -- Try some ideas (usually selected by a vote)
• Choose -- Pick the winners
• Implement
• Learn

Why should you care? The board of the Open Source Initiative has largely concluded that we have reached a point of organizational and contextual maturity. Namely, that open source has been defined, and a relatively large constituency of people have accepted that definition. So far, so good. What we have not done, however, is to make the OSI representative of that constituency. Yes, our board members have strong credentials as open source software developers, entrepreneurs, advocates, researchers, etc. But we cannot really claim that we are truly representative of the community, nor that we can truly speak for the community, other than the fact that each of us considers ourselves to be a small (very small) part of the community. There are others who identify themselves as members of the open source community (just as we do), who strongly believe that they better know how to protect and grow the open source movement, which includes greatly relaxing our standards for interpreting the OSD and allowing a great many more licenses to be approved. There are others who think that the OSD should specifically permit new and different ways that authors can control the use and distribution of their works. Etc. You may agree or disagree with these positions, but who gets to judge who is right? How are board members nominated and elected? How well does that process represent your position? We believe that one way to address this is to transform ourselves into some kind of membership (or other representative) organization. But what, precisely, should be the goal? And what should be the process? And how should it be done? And how can we protect ourselves if 50,000 people who want to destroy open source decide they want to join and vote us into the ground? This summer, five thousand or so open source community members will meet together in Portland Oregon at the O'Reilly Open Source Convention. This strikes us as a perfect opportunity to use an inclusive, design thinking approach to answer some of these questions. I hereby volunteer to lead two sessions during a BOF at OSCON. The first session will be a primer on Design Thinking: what it is, how to do it, what not to do, some examples of successful design thinking. The second session will be the application of design thinking to the following problem: How Should The OSI Transition to a Membership Organization? In my experience, 80% of all design thinking sessions I've attended result in a redefinition of the problem statement because in the process, we realized that we started off trying to solve the wrong problem. This is why problem definition is a part of the process, not an input to the process. Thus, it is entirely possible that the outcome of the session will be to solve some other problem. And if we do the process well, that will be a successful outcome! In any event, if you do plan on coming to OSCON, please plan on attending one or both of these sessions. The first (on design thinking) should be strictly useful in any context. The second (on OSI governance) will be as useful as you are willing to make it. I hope to see you there!