[zeromq-dev] 0mq in Moscow

[Pieter Hintjens]

On Mon, Nov 1, 2010 at 5:00 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> "Release early, release often" principle has some drawbacks. People look
> at an early version that is not stable enough and then avoid the project
> even though it may have stabilised in the meantime. I think Joel Spolsky
> had a blog about this long time ago.

That's one conclusion.  The other conclusion is that if you always
take a version through to stability before starting on new
functionality, you have a stable (fully working) version people can
trust plus an unstable (richer) version people can experiment with.
There is no real justification for having unstable code for more than
a few weeks, let alone months or years.

In 0MQ's case, we could have started with one pattern, one transport,
and when that was totally stable, expanded it.  This is the industry
standard model for open source projects, 0MQ shouldn't be any
different.

There were specific unfortunate design aspects of 0MQ such as the use
of asserts for error detection rather than internal consistency
checking, and the lack of documentation on the protocol which made it
harder to model explicitly and therefore to check.

We learn these things, but releasing less frequently would make things
worse, not better.

-Pieter