Pieter Hintjens

The section on security is just... bonkers.

First it starts by talking about how ZeroMQ security is an "afterthought", linking to an article that should hopefully convince even people with casual security backgrounds this isn't the case: http://hintjens.com/blog:48

For what it's worth: ZeroMQ implements the closest thing to a real-world implementation of Dan Bernstein's CurveCP protocol, with a few design flaws fixed, and also a certificate form that allows a limited hierarchical PKI. Normally I'd say using anything other than TLS is a huge warning sign, but as far as non-TLS protocols go, ZeroMQ's "CurveZMQ" protocol actually ends up looking fairly good in my book.

Iris does none of this, advocating the use of global PSKs. Global PSKs are the bane of security professionals everywhere, as they make any system that shares the PSK the weakest link, greatly increasing the chance that the most overlooked system will become a vector for total system compromise. This is why we've generally seen a move away from such systems to running internal PKIs with unique keys per host.

Instead, they claim:

"This is achieved through the observation that if a node of a service is compromised, the whole system is considered undermined."

This is pretty much the opposite trend of modern crypto practitioners.

It's been awhile since I actually looked at their crypto, but at a cursory glance-over again it's hand-rolled and uses bignums without random blinding, greatly increasing the chances…

I wasn't aware of this particular workflow, but I've heard of similar ones before. The late Pieter Hintjens, of ZeroMQ fame, advocated for a strategy called "optimistic merging"[1], which essentially abandons the standard code review process in favor of merging changes ASAP, and fixing any issues as they arise later.

I'm not a fan of this. It allows contributors to abandon any established coding standards, while placing more burden on maintainers to fix issues later. This in practice never happens, so the quality of the codebase degrades over time. Not to mention that it allows malicious actors to merge changes much more easily.

As for "ship, show, ask" specifically, I have similar reservations. I think all changes should go through a review process, even if someone just glances at the changes. It not only gives the opportunity to leave feedback, but also serves as communication so that everyone is aware of the proposed changes. Also, making the decision of whether to choose "ship", "show" or "ask" might only work for senior and well disciplined developers. I think that in most teams you have a mixture of experience, so you'd inevitably end up in situations where a change should've been "show" or "ask", but was "ship", and viceversa. I don't think teams will ever align on a single strategy to make a correct decision, since it's based on subjective opinion to begin with. Always following the same workflow gets rid of these uncertainties.

[1]: http://hintjens.com/blog:106

> Does anyone have examples to share of open source projects that have very low friction for drive-by contributions while still maintaining quality? Projects with very clear documentation and instructions for contributing?

Yes, absolutely. Read https://rfc.zeromq.org/spec:42/C4/.

We developed the C4 contract (in the form of an RFC) precisely to teach maintainers how to welcome new contributors while keeping quality high. It took many years to refine this approach. By formalizing it, it becomes really simple for projects to adopt: all you need in your README 'Contributing' section is a license (we recommend MPLv2), a link to this RFC, and later a style guide to ensure consistent code style.

The thing about C4 is that it teaches people to make small testable patches, and to trust new contributors. We know from experience that it's users of a project who keep it alive. Original authors and core maintainers burn out, get full time jobs, start new projects. As long as you have users, though, you have potential contributors.

Small patches, merged immediately, with reviews and improvements made asynchronously over time. This style is lovely to work with, kills bike shedding (we argue with new patches rather than comments), and reduces the friction in the project to as low as possible.

More on optimistic merging: http://hintjens.com/blog:106

In terms of friction: we aim to get a patch live on master within a few minutes. If that breaks master, we fix it either with a new…

You have to get people there, and you have to get them to want to bother coming back.

1. raise awareness. e.g. though word-of-mouth recommendations, or advertising (online, TV, events, IRL?)

2. it has to have something to keep attention,

3. it has to be worth coming back to

It happens through phased growth, sometimes explicitly planned, always interactively managed. A marketing and sales pipeline provides a google-able articulated view of a similar process. Or go as far "Manufacturing Consent"

They're built on positive feedback cycles, where contributions spur further engagement of viewing, and prompting others to engage. These are called virtuous cycles, when it's going in a desired direction (e.g. more contributions drive more views drive more contributions), and vicious cycles when they're not (bad drives out the good, e.g. toleration of off-topic / inappropriate content, deters helpful contributors from returning, while encouraging more detrimental contributions).

I would recommend reading Peter Hintjen's "Social Architecture"[1]. He addresses a question worded exactly the same as yours. He built a more narrowly scoped community as an integral part of building the ZeroMQ messaging library and tools, and ensuring that it was useful to as many people as possible.

Also, check out his other books [2]. Though, note that gitbook.com broke the links, and…

> the greater opportunity there is for a manager to take wealth

Pieter Hintjens (creator of ZeroMQ) wrote a lot about this, and how organizations from big companies to small charities to software projects ought to design their internal structures of roles, titles, voting, auditing, to defend themselves against this kind of attack. Particularly if there's any kind of treasury, an opportunist will become tempted to take that role, but any kind of credit will attract people who want to take the credit without doing the work, power structures will attract people who want the power, and programmers who "just want to code" and avoid politics will find themselves at the bottom of a dysfunctional infected organisation structure with no power, no credit, and being instructed by distorted requests.

IIRC he tried to design the ZeroMQ organisation so that there wasn't any way for one person to insert themselves in a key point.

I'm not sure where on his blog I was reading that, but it's related to his writings about psycopaths[1] as the opportunists, and might be part of his book Social Architecture[2]

[1] http://hintjens.com/blog:_psychopaths

[2] http://hintjens.com/books

As someone who only discovered Pieter by finding his last article posted on HN, and then subsequently learning a lot from reading many of his other articles on his website (different perspective on life, humility, consulting in tech outside of SV, presentations), here is his homepage for those who are curious: http://hintjens.com.

Three examples I'd recommend:

Life, Consulting, Humility, Calming Down: http://hintjens.com/blog:125 (confessions of a necromancer)

Presentations: http://hintjens.com/blog:107 (ten steps to better public speaking)

Life, Humility, Time: http://hintjens.com/blog:123 (fighting caner)

He's one of the few online writers who keeps my attention no matter the length. His humor is fun and his imagery and story telling style are engaging.

[edit: formatting]