[geocar]

> …highly opinionanted/unusual setup…

That setup contributed to security.

It also made qmail very easy to extend: I operated a medium-sized mail service a while ago and qmail's pluggability meant I could add features that didn't exist in other mail servers (like postfix or exim) without forking the entire project.

* I had SMTP AUTH when the only other mail server to support it was Netscape; before RFC2554 was written.

* My qmail-popup proxied to another machine so it didn't need root (making me immune to the Guninski vulnerability) so my users only needed to know about a single hostname regardless of where their mail was stored, and without needing to use something icky like NFS.

* I had a web interface with auto-enrolled client certificates for authentication and confidentiality for SMTP, POP, and IMAP.

* My qmail-remote recognised certain suggestions our IP was being blacklisted and would retry immediately with a new IP.

* My qmail-remote recognised certain greylisting error messages and rescheduled retry for that time.

* I had multiple mail queues based on the number of retries the message had seen.

And so on. I didn't start out to make those features, they just grew over a decade or so organically. At no point would I have forked postfix or exim to add any of those features because once you fork it you own it unless you can get your changes upstream. I had shit to do, so the real alternative was simply buy more servers and/or pay for commercial software.

I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later...

> …and unwillingness to share and collaborate on its development…

Dan absolutely collaborated, and I certainly was using betas back in 1996.

If my memory/anecdote isn't enough: There are a number of explicit points of evidence in the changelog distributed with qmail.

What he doesn't do is let people save face when they say something incredibly stupid and then try to backpedal when it's obvious how wrong they are. This bruised more than a few egos, and contributed to a campaign to actively smear his name and discredit his software.

> It could have easily dominated the market…

I think if Dan had let the peanut gallery have their way, we probably wouldn't have gotten postfix, but then qmail wouldn't have been qmail except in name. What's the value in the qmail brand if it isn't secure anymore?

[Steeeve]

Having strong personal convictions about security and architecture was one of the primary reasons that tinydns and qmail were the staples that they were.

Yes, they have been feature locked for a long time. But let's not pretend that collaboration in 1996 was anything like it is today. And let's not pretend that there haven't been a plethora of security issues in all kinds of software that simply haven't befallen Bernsteins' software as a direct result of how he managed the projects.

I had the distinct impression that "dominating the market" was never a thought in his mind. He wrote the software he wanted to write and shared it. It was good software. It's still being used by many people.

The man isn't infallable. He isn't always right. But whenever I paid attention to him, he was right a lot more frequently than he was wrong.

The fact that he wasn't driven by dollars or market dominance was a good thing.

I, for one, admire the man and his software.

[oblio]

> I wish the model had caught on, because it's a superior way to develop software. I didn't understand why though until fifteen years later...

Can you elaborate?

[geocar]

Which part. The model? The article explained it well enough. I think of it as two main parts: (1) make fewer bugs, and (2) show your users the correct way to do things (which is the inverse of getting the correct requirements).

Or are you asking what took me fifteen years to understand?

Dan basically planned the whole thing. When the whole thing was too big, he would break off a piece that wasn't and develop it as a wholly separate thing.

I understood this strategy worked, but I didn't fully understand why this strategy was successful until I realised source code matters more than I thought[1]: If your program is short enough, there won't be any bugs in it. This is why learning how to read and write dense code[2] can make your programs better -- and that's what I learned how to do[3].

[1]: http://www.jsoftware.com/papers/tot.htm

[2]: http://www.nsl.com/papers/origins.htm

[3]: https://github.com/geocar/dash/blob/master/d.c#L62

[hursortue]

> learning how to read and write dense code

> and that's what I learned how to do

This is good code?

  for(i=b=0;i<r;++i){switch(p[i]){
  case'\n':if(!e)e=i;if(!q){q=kpn(p+w,g-w);if('\r'==(cf=p[i-1]))cf=p[i-2];}else if(!c){w=!!strchr("kK1",cf);if(!o)sc(d,0,sd);else if(w){if('g'==o)cwrite(f,OK("200","keep-alive")BLANK);else cwrite(f,OK("204","keep-alive")END204);}else{if('g'==o)cwrite(f,OK("200","close")BLANK);else cwrite(f,OK("204","close")END204);close(f);}a=k(o?-d:d,"dash",knk(2,q,xD(a,v),0),0,0);b=i+1;if(!o){if(!a){poop(f);R 0;}if(10!=a->t){r0(a);poop(f);R 0;}writer(f,kC(a),a->n);r0(a);if(!w)close(f);}if(b==r)R 1;q=0;o=0;a=ktn(11,0),v=ktn(0,0);}else{if((c-m)==10&& !strncasecmp(p+m,"connection",c-m))cf=p[s];js(&a,sn(p+m,c-m));jk(&v,kpn(p+s,e-s));}w=e=g=s=c=0;m=i+1;break;
  case' ':case'\t':case'\r':if(w&&!g)g=i;if(s==(e=i))++s;break;
  case':':if(!c)s=1+(c=i);break;
  case '/':if(!w)w=i+1;case '?':case '&':if(r>=(i+4)&&p[i+1]=='f'&&p[i+2]=='=')o=p[i+3];default: e=0;break;}}if(a)r0(a),r0(v);if(q)r0(q);R b;}

[fiddlerwoaroof]

That's how people with an APL background write C and it is, in fact, readable to those people: to me, however, it's gibberish

[geocar]

It could be shorter if I spent some more time on it.

[irundebian]

LMFAO