[zeromq-dev] Moving to 0MQ/3.0, yes or no?

[Pieter Hintjens]

On Sun, Apr 10, 2011 at 10:50 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> Well, my point is that backward uncompatible changes are painful for
> everybody, especially those having the code in production and language
> binding authors.

You don't seem to be listening.

Antoine Boegli:

"IMHO, if the changes are previously documented and discussed this
should be okay with everybody. I really don't like to be surprised
with API change or tool/function removal (zmq_device in my case) when
there is no clear answer to "what can I use instead and how?"

It is not a matter of painful change. It took me 30 minutes to make
libzapi work smoothly with the 3.0 API. The software part is easy.

Here is what goes wrong when you make changes to stuff people use,
without prior discussion:

* People get surprised and annoyed
* People don't have time to properly plan alternatives
* What one makes is inconsistently named, under polished, and under documented

If people find change painful, they will say so, but I've never seen
anyone complain about change as such. What is painful is lack of
upfront discussion, and feelings of ex-cathedra changes that don't
address actual and obvious needs. Look at any Hacker News discussion
on 0MQ and you'll see the same complaints. It still has random
asserts. It's too easy to crash nodes by sending them junk. The poll
API is horrid. etc.

It's kind of a truism that any developer who doesn't present his ideas
for upfront debate will end up making avoidable errors. In the worst
cases, smart developers who don't use their own products often think
their users are stupid and unable to grasp the "big picture", and then
we end up with real conflict between users and developers.

A good thread, for 3.0, was the discussion of the messaging API. But
it wasn't based on written proposals. There is no conclusion. Just
passing discussion. I'd score it 6/10.

Please, Martin, document your ideas up front, discuss them on the
list, get consensus and improve the documentation until you get
consensus, and *then* move to make change. Make changes one at a time,
get into actual use, and proven, then move on to the next one.

If you don't do this, people will eventually lose trust in your work,
no matter how brilliant it is. You either bring your users deep into
the thinking process, or you will work alone on stuff that interests
only you. I speak from personal experience.

-
Pieter