[OT] Release soon, release often

[fog]

I didn't anticipated to write about that but after 3 month following the Ogre forums I feel it is time to share what I think about "open source" (mandatory quotes.)

We see a lot of talk about "open source" and a lot of binary only demos and screenshots. I don't know exactly why but it seems that people doing 3D (or maybe is people programming on win32?, I don't know..) don't want to release half-finished code. "When the code would be in releaseable state".. is the phrase you read more on the forums. If you plan to release first or later, this is bad. An earlier release means less bugs, less "wrong turns". less code duplication. Less work and better results. We all (apart from Sinbad and the glorious Ogre developers ) write crappy code in a hurry to test some new idea. Sharing that code now is the Right Thing (TM) to do. Maybe is crappy (mine sure it is) but it will help people working on the same problems a lot.

You plan to write the next big hit in the 3D game industry? Keep your code proprietary. That's perfectly fine. To publish your own code is a choice.

But if you think you're doing something nice, something you'll want to share when it is "finished" sometime in the future? Please, release now. Nobody will judge your coding skills and everybody will be happier.

Sorry to bother but seeing 2 or 3 projects with almost the same aim was too much for my free software heart.

End of Off-Topic. Back to coding.

[Clay]

I'd say that's pretty on-topic. =)

Especially with all these WIP tools running around. You guys post impressive screenshots, but unless we beg you to post code up we rarely see these come to fruition. There also doesn't seem to be much collaboration with these things.

Hell, look at PyOgre. I release a version after about 3 bug fixes/enhancements. I post screenshots and release very often. What's happened since I started getting people interested in the project?

Vasily Sulatskov wrapped up the CEGUI OpenGL renderer and got it working with pygame (you don't need pyogre to run pycegui anymore). Fog did the work to get pyogre to build on linux. bjourne overcame the problem which caused pyogre not to run under linux (though he says there are more problems). All of this from a half-assed building instructions that is multiple versions out of date, and a source tree that has maybe 3 meaningful comments in the entire thing.

Don't understimate the power of open source. I propose a challenge to anyone working on a tool right now: Build a demo, and include the source. Don't bother making the demo bug free, just make it run.

See what happens. I'd be willing to bet you'll find more interest than you imagined.

[spookyboo]

I think the Ogre community is very open and I see more code than I can handle. I don't share your feeling that people are holding back in sharing code. If you need something specific, then ask for it.

Regarding the WIP tools: I'm not surprised that people are working on the same type of tools. People are aware of the tools that are missing and have to fill the gaps. This 'gap' is different for every person. In most cases they try to fill it as fast as possible, because behind it, there lies the real objective. So they take some short cuts, only implement what they need and compare it with the tools other people are working on. They come to the conclusion that it's not exactly what they need and everybody is moving on.

I agree that more cooperation is the keyword here and we should focus on tools that are useful for most people, have an open architecture and are easily expandable. This means that some of us have to forget their real objective (for now) and make tool development their objective.

[Kencho]

I personally think people just doesn't release the code because almost every project is developed in a rush, with many patches and messy code with bad programming habits. I'm one of those, and personally, when I code that way, I prefer to have things finished first, then clean the code, and finally release it

[DWORD]

I also think it's important not to release the code too early. Of course the code could be useful to other people, and as such I'm all for releasing as much code as possible, don't get me wrong. But if you want to collaborate I think it's very important that there is a good base and a strong lead before everyone jumps in and implements their own features. If the code is released too early there's a risk of feature-bloat and getting messy and unmaintainable code in the end; whereas a deliberate initial release with good design and extensibility has a much better chance of becoming a success. Take Ogre as an example.

[sinbad]

I think like everything, there's a balance point to this, and it does depend on the kind of tool you're making.

I agree very much with DWORD that for open source libraries to really take off well there needs to be strong guidance at the core. Open source works really well, but actually only in similar ways to 'normal' teams in that if there is no vision and direction setting which a small number of people (perhaps even one person) champions and defends, it's not going to work well.

I don't claim to have the answers, but my personal experience is that a kind of 'hub and spoke' system works pretty well. That is:

1. decide very early on the core responsibilities of your library. Be ruthless about what is out of scope - it's really tempting to start subsuming everything into one uber-library, but that's infeasible. Cohesion is key - everything that's in your library should contribute direct to that core and easily describable purpose - everything that doesn't should be shaved off pronto.

2. Decide what else your library needs to interface with. A lot of that will be what you shaved off in point 1. Design an interface system that doesn't care about what those 3rd party systems are, but nevertheless has the incoming and outgoing hooks that they will need. Abstraction is key.

3. Defend 1 and 2 vehemently. There will be repeated calls to break the rules and to start becoming the uber-library; that way leads only to madness and no matter how sane the suggestions might seem in the short term, any proposal that does not fit into 1 and 2 must be denied.

By being ruthless about 1 and 2, you actually enable the community to get on and build collaborative projects better, IMO. The reason is simple - the core has a clear design and purpose so everyone understands it and tends to pull in the same direction; there isn't any room for people to run off doing their own thing with it. In addition, because the core scope is kept tightly focussed and the interfaces deliberately enforced, related projects can spin off and work autonomously because the core doesn't need to know - hopefully they will apply the same principles, but in the end that's up to them.

So IMO, successful open source isn't about collaboration on a completely free-for-all basis, even though ostensibly that's what it might look like. It's about freedom to participate within a well defined but nevertheless open team structure. Getting the core principles right is so important.

Having said that, smaller tools don't perhaps need such a rigorous approach, although in practice that's because only a small number of people might be working on them at one time. It's believed that human brains are hard-wired to collaborate directly with perhaps 6 other people - beyond that number and you need mor formal structures in place to manage it.

[PeterNewman]

Something else that's not mentioned here is LGPL and code release. I know that informally, people don't really care, but if you're trying to do this semi-commercially (or fully commerically) you have to be very careful about following the letter of the law.

I'll use my project as an example. We release Alpha's that are not publically available. Any-one who can get the binary can get the source (as per the LGPL) but we have an understanding the binary is to be kept private. These are the "I dont know if this will even compile" releases.
We will be releasing a Beta very soon (probably this week) and this will be public. Nothing is guarenteed to stay the same, documentation is take it or leave it, but it should technically work. Any-one who can get this binary can get the source, at the point the binary was compiled.
Eventually we will release a 1.0 release, with all the gaurentee's that go with it.
Note that our current dev/HEAD code is only available to our alpha testers.

Now, the part that relates to the rest of this thread is, the point of this is so we don't get swamped. We plan to hand-check every bugfix and patch, since while the product is free, we are basing our commercial ventures on it (content development etc) and need to maintain a level of quality. Everything gets to go through (at this stage) my hands, to make sure things being added are being done right. We want public support and development, more eyes and so on, but if the project gets off focus, it will flounder.

So, I agree with release early, release often, but I just add: Release to people who are going to give constructive feed-back, at least at first. This pretty much includes most of the Ogre community (you guys all rock).

Of course, when it's more of a hobby and a "I did it because I wanted it" thing, like most projects here are, the rules are different. Just wanted to share another perspective.

[fog]

So IMO, successful open source isn't about collaboration on a completely free-for-all basis, even though ostensibly that's what it might look like. It's about freedom to participate within a well defined but nevertheless open team structure. Getting the core principles right is so important.

I completely agree. But you're talking about good project management practices and only a fool will disagree. Checking in patches from everybody is evil. A solid and well-designed base is very important for a successful project. And that's all. To put it simply, again, I agree.

But I was talking about something different. I was talking about tons of bad-but-good code being lost. What I mean bad-but-good? Code written in hurry but that show how to solve a specific problem. Code that can be ported to another platform even if the original author doesn't care anymore or disappear. Code that can help me even if didn't meant it.

Getting early comments and patches on your code is important but that's not I was advocating. I was saying that if you plan to release (emphasis: "plan to release", I'am not saying anybody should do so), releasing early is making your code usefull from the start. Not for what you planned it to do, but for what other people can find in it.

[Kencho]

a.k.a. Code Snippets

[johnhpus]

I agree with that idea fog. I've got a few chunks of code like that myself. I know it would help new users and those with less knowledge than me but I haven't had time to get around to cleaning it up and commenting it. It might be hard to prevent an all-out crapfest, but a sub section of the code section on the wiki might serve as a place for dirty but working code.

That, or I could thank of all of those who helped me by going through the effort to make it more "releasable". I guess we'll see how it all works out.

[jacmoe]

That is what wiki is for!
Put up some code there, and other people will learn, add to it, adjust ...
It is code snippets on rocket fuel