[nanomsg] mangos and libnanomsg projects, relationships, and governance

  • From: "Garrett D'Amore" <garrett@xxxxxxxxxx>
  • To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
  • Date: Thu, 17 Dec 2015 10:18:38 -0800

This was an old question, and going back through the archives, I see I
failed to answer it.

mangos is an independent implementation of the SP protocols — it was
written from scratch to be wire compatible, in idiomatic Go. It will
remain so for as long as I am the owner/maintainer of it. I have also
explored some other capabilities, such as adding SP over TLS, and
integrating within the Go websocket and HTTP frameworks. Those would be
unrealistic to accomplish using libnanomsg. (Also, by being idiomatic, it
quite likely outperforms native C / Go translation, and certainly fits
better within the Go concurrency model.

None of this is affected by the fact that I’m also now the libnanomsg
maintainer. Apart from sharing specifications, the two projects will
remain independent.

libnanomsg was started by Martin Sustrik, who also wrote the vast majority
of the code. Its more a community effort these days, and while I’ve taken
on a “benevolent dictator” (maintainer) role for it, that’s not a position
I’m happy with. I’d be happy to either step down, or share leadership at
some point, for libnanomsg. Right now the single biggest hurdle here is
getting sufficiently expert contributors who have both time and interest to
step up and share this responsibility. I suspect there is at least one
individual here who would make a good candidate for at least joint
“maintainership”. (I’ll reach out separately.) It’s unfortunate that the
libnanomsg is as complex as it is; its unapproachability is perhaps the
single biggest problem with it. (That nice friendly sockets based API you
all love is backed by a hairy beast underneath.)

mangos is different. That’s my project, and while there have been some
good contributions, I feel a much stronger sense of ownership. Whereas
working on nanomsg is a job that I often detest, as its difficult and the
convoluted state machines are definitely not how I’d like to implement
things, mangos is the opposite for me — I truly enjoy working in that code
and indeed I often resent the time that libnanomsg steals from me that I’d
rather be spending towards other ideas I have for mangos. So even if I put
mangos into a top-level github org repo, I don’t intend to change the BDFL
nature of its organization. The top-level github account is more about
wanting to make the project more readily discoverable, and to reserve the
name against any future where I might not be the maintainer. (Nobody lives
forever, and I imagine at some point I might want to move on — even if I
can’t imagine *when* that might be.)

As to a hypothetical rewrite of libnanomsg, I’ve spent some effort thinking
about this, and even written some initial code. That project, if it ever
takes off, will probably be independent of libnanomsg proper as well.
Because it would have different design goals, and an incompatible API.
However, assuming that I ever do such work, I might then be willing to
discuss whether it becomes some kind of “semi-official” or even “official”
successor to libnanomsg, and if it did that would I then be open to a more
open governance model for it. But in any event, such a rewrite remains
strictly hypothetical at this point, and I wouldn’t plan on seeing it any
time soon. Indeed — sustaining tasks on “current” libnanomsg are
sufficiently time consumptive that I really have no time to take on a new
major open source coding effort — I don’t even time to allocate to the ones
I want to (which are various — from illumos kernel projects, to Go based
terminal stuff, to mangos, and even a game I wrote in Go — and yes I resent
libnanomsg from stealing time from all these tasks and interests.)

I hope that clears up some questions for folks.

— Garrett

Other related posts: