Several people wrote me about yesterday’s essay (Embracing my Inner Dinosaur), suggesting that I consider going the open source path. I spent some time looking into the current state of open source work, and I must confess, the universe of open source has expanded faster than the Big Bang. I rummaged here and there, looking at all the schemes and variations. It truly is impressive, and I certainly find it appealing. I am sorely tempted.
However, there’s one drawback that, for the moment, seems compelling. The benefit of open source is that I obtain the contributions of others. The cost is that I must work with others. Such an arrangement, in the norm, is quite efficient. Each person brings different skills and ideas to the team, and the team as a whole is therefore stronger than any individual. But my case is far from the norm because there’s such a great difference between my own design thinking and that of others. In a healthy open source team, everybody is animated by the same basic conceptual foundation. But me, I’m weird. Can you think of anybody who thinks about game design like Chris Crawford?
This would not be a problem if the project were a conventional game, but any project I do will be a wild-blue-yonder project, one in which we’re going where no person has gone before. Our path will be murky. I’ll be relying on design instincts developed over 30 years of trial and error. Those instincts will lend confidence to my efforts, a confidence that will not be shared by my colleagues who have not spent so much time walking in utter darkness.
The consequences of this were driven home to me at last year’s Phrontisterion. I challenged the group on several occasions to decide upon the most promising strategies to deal with specific problems in interactive storytelling. Each such challenge was rejected on the grounds that the state of interactive storytelling is still too immature to permit such decisions. I found this immensely frustrating, because I was raising issues so fundamental that, in my opinion, anybody who has worked on the problem for any length of time should have formed some opinions on the matter. Indeed, for me, every issue that I raised was, in my opinion, something that I myself had solved many years ago. They were saying that the world was pitch black and therefore there was no basis for deciding on any particular direction. I was saying that the light was dim, but I could make out the form of the mountain in the gloom. They thought me narrow-minded.
The same problem would poison any attempt at open-source collaboration. My next big project will be Siboot, based on a design I built in 1987. I have been thinking about this design for years, and have already done a great deal of preliminary work on the design. I have not yet properly documented the most important component of the design, a language of interaction I call SympolTalk. I have a very clear idea of where this design will go. If I go open source, the people who’ll be committing lots of time to its development will surely want to have some say in the design – and I think they’ll have every moral right to demand it. But nobody can possibly have as clear a sense of direction about Siboot as I can. I will surely end up shooting down most of the ideas they proffer. That in turn will be demoralizing to them, and one by one, they’ll stomp off to implement their own ideas themselves.
This would put me in a worse position than I would be if I did it all myself. I am not a good programmer; I am an adequate programmer. My code is simple-minded and based on a primitive appreciation of software technology. For the Storytron project, I recruited two top-notch programmers to tackle portions of the code that were beyond my capabilities. Now that the project is over, I have no idea how to edit their code; I don’t understand it. The same situation would arise with an open-source project.
It’s certainly conceivable that I could launch an open-source project for Siboot with a clear up-front statement declaring just how constrained the creative input of team members would be. But consider: the only people who’d be willing to participate in such a project are the starry-eyed dreamers, and such people have dreams of their own. If I ask them to help me with my dream, and then repeatedly reject their own dreams, they will surely be disillusioned.
I’ve already had this experience, on several occasions. The most recent was with SWAT, the authoring tool for Storytron. A lot of people were excited by the idea and volunteered their reactions and ideas about the technology as it developed. They assaulted me with a wave of suggestions, which I mowed down with all the ruthlessness of a German machine gunner wiping out lines of charging French soldiers at Verdun. But I still felt a lot of pressure to accept at least a few of those suggestions, and I gave in on one idea that I knew was bad: assigning spatial locations to stages. Everybody wanted that feature. I relented and it was implemented. And it was a disaster. It vastly complicated the system without any concomitant improvement in dramatic potential. This was a classic situation. The volunteers were all techies, and techies are profoundly spatial in their thinking. They simply could not grok a system without spatial expression, and so they absolutely had to have spatial coordinates.
I suppose that I could obviate this particular manifestation of the problem by declaring in a design document that there will be no spatial factors in Siboot. But the underlying style of thinking that triggered the spatial problem will not be changed.
Hold on. (This is the reason why I write these essays. Putting my thoughts down in writing forces me to carefully consider each step in the line of reasoning, which in turn clarifies the issues and often results in new ideas.) What if I were to prepare a thorough set of design documents in advance? All I have to do is continue with the design diary for Siboot, developing my design concepts as clearly as possible, until at last I have a set of documents that clearly specify the design, as well as specifying those areas where the design is unclear and I am open to the suggestions of others. When the design diary is in good enough, I launch the open source project, advising candidates that the design will adhere to the specifications in the design diary. That way, they know up front what they’re committing to. They won’t be disillusioned if they suggest an idea that I point out conflicts with some statement in the design diary. And they will know the areas where I’m open to their ideas.
By Jupiter, this could work. I must think further upon it.