Network Games - Open Source the Server, Let Others Write Clients?

xihr asks: "I'm the developer of Interstelen, initially a turn-based, strategic Web game of interstellar conquest. As time has progressed, I've found that it hasn't gone much beyond the barely-usable, early-alpha phase, primarily because, as with most people, I don't enjoy making user interfaces. It's clear at this point that it's not going to get done unless something changes. So my choices are to put the game on hold, or to change the architecture and goals. It occurred to me that this might be a better approach: Architect a server and public protocol, as well as client libraries for a few languages to help people along and a trivial text-based client primarily for a code example and debugging, and 'recruit' (hopefully, just 'let') people to write various clients." Seems like a reasonable strategy, especially if time is a limited commodity. I'm sure there are Slashdot readers who are working on (or have done) similar project. How did things turn out?

"This isn't too different from my ultimate goal, which was to eventually release the code under open source anyway and to eventually put together a public protocol so that other clients could be created. In a way this would be simply reversing the order in which things get done.

This would be win-win, since it would play to my strengths and people who like making user interfaces could make them in whatever language they wanted. But obviously it's not going to get anywhere unless people are actually interested in writing clients, so there's a chicken-and-egg problem lurking here.

Does this sound like a project that would be of interest to the open source community?"

"Let others write" = "Let no one write"

[mcelrath]

Having started several projects and watched several others, I can tell you this with confidince: In Open Source you cannot depend on other people to write pieces for you.

1. In early stages, everyone wants to start his own project. Nobody wants to be a small piece of a larger project. I have tried to corral people working on similar things as me into one project, but no one is willing to give up their ideas and control in order to be a third-tier contributor to a larger project.
2. People will generally not contribute at all unless the current product is usable, and sufficently compelling to make them want to improve it. A half-baked idea or a half-finished client will stagnate indefinitely. One only needs look on sourceforge for the 80% of unfinished projects there. You know, the ones with no code, or a little code but not yet working.
3. If other people do contribute, they're not going to implement your ideas. They will implement their ideas. Almost nobody joins a project, and picks something randomly from the TODO list. In my personal pet project [sourceforge.net], I don't think anyone has ever written something that I put on my TODO list. Though I have received several contributions that I didn't think of.

So I say this to all open source developers: Look for and join another project, rather than starting your own! Open Source would go a lot farter, a lot faster, if so much effort wasn't wasted on projects that eventually dead-end. Imagine the effort that went into each of those projects went instead into larger a larger project!

On the other hand, writing a generic library is often exactly what is needed. In your case, a generic server and client library might be a good idea, but it must be sufficently generic and you'll have to give up on the idea of people implementing your kind of client. You might be surprised what it gets used for. (Software is funny that way) For instance, gstreamer [sourceforge.net] seems to have given up on writing the be-all and end-all media player (a la mplayer [mplayerhq.hu]), in favor of writing a component library for media playing. It remains to be seen whether they will be successful, but I think they will be. This route is difficult, and requires a lot of evangelism. Not everyone will agree with your design decisions, so not everyone will want to use it.

-- Bob

UIs aren't that hard

[markj02]

Writing user interfaces in C or C++ is an absolutely dreadful process (although C and C++ are good for other applications). But if you use the right languages and toolkits, it becomes a lot easier. I like Python with Tk or wxWindows. Smalltalk (Squeak) is also quite nice, but a bit hard to deliver. Java/Swing is almost as tedious as C++, but at least the toolkit is very complete and there are lots of third party libraries that help you and that all work together.