[zeromq-dev] 0MQ/3.0, 0MQ/4.0 and 0MQ process

[Pieter Hintjens]

On Sun, Oct 30, 2011 at 7:26 PM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> The problem with early design is that you get it wrong for the first time
> anyway.

Indeed. Look, I've spent decades making elegant, perfect software that
was close to irrelevant. Here's what I do these days (and it works
better):

* make sure every single piece of work is solving someone else's
identified problem
* make minimal plausible answers to these problems
* ensure they are tested rapidly

Removing barriers to participation, making rapid release cycles,
releasing raw code are valuable aspects.

If you want to do pure experimentation and research, it's natural to
work in isolation but the results will often be flawed in ways that
only become visible very late. You need the diversity and scale of a
smart community to get accuracy early on in the thought process.

</end of philosophy>

> Agreed. It was the only politically viable solution at the time.

And it's worked, we've been able to make huge progress with little pain.

> Yep. Still, multiple workflows is annoying and confusing my hope was that we
> can make a step -- however small -- towards unifying them.

I fully agree. It is confusing. It's unclear whether that confusion is
bad. Chaos can be useful in itself because it allows much more
experimentation and has fewer points of failure. Distribution vs.
centralization, we know the trade-offs. This applies to knowledge too.

> Anyway, fair enough. The above means there's not going to be an unified
> process for 0MQ project either now or later. I have no clear opinion on that
> at the moment. I'm going to think about it a bit more.

IMO the search for a unified process is misguided and potentially
destructive in itself. We're a large and complex community where
libzmq is one of many projects. It is at the heart of everything but
does not define the rest, and should not. Diversity is essential. This
is why I've always supported your wish to have signed-off patches via
email. It works for you.

> IANAL. I have no idea whether the fact that any licensing problem can be
> tracked to individual person's fraudulent "certification of origin" has any
> legal ramifications. However, I guess the matter was reviewed by layers when
> introduced to Linux kernel process and deemed worth of doing.

It's not even about licensing (pull requests solve that). It's about
avoiding SCO-type lawsuits, which realistically were (a) historical
one-offs and (b) focused on the Linux kernel. I consider this to be
originated by enterprise lawyers who wanted a way to shift potential
liability to individual contributors. The problem is not real.

> If the users of 0MQ feel that eventual legal protection resulting from
> signing patches off is not worth of the effort, I am happy to drop the
> policy.

There was at no stage anyone who identified this as a problem. We
should always be skeptical of assumed problems. Doing what other
projects do just because (a) they do it and (b) they are successful is
cargo cultism.

I'm saying, drop this. No-one needs it, it's clumsy for contributors
and reduces participation. Which makes it bad for 0MQ, not good.

There are real risks to 0MQ such as hostile attack by threatened
corporate interests, and the answer to all of them seems to be the
scale and diversity of the community. So I'd conclude that the
sign-off policy is actually dangerous.

> Ok, if there's a way of doing it technically, no problem about that.

Define the problem, state categorically that "it's impossible", watch
people solve it. :-)

-Pieter