Why I Don't Care About Brendan Eich's Prop 8 Donation

The social media universe is all a'twitter about Brendan Eich's recent promotion to CEO of the Mozilla Corporation (MoCo). Brendan Eich is, as you probably remember, the guy who invented the JavaScript programming language. Eich was at the time, an engineer at Netscape, moving over to the "Mozilla Organization" in 1998 and then the Mozilla Foundation (MoFo) in 2003. By this time he had risen to a position of technical leadership and was, in fact, one of co-founders of the official Mozilla Foundation 501(c)(3). As the Mozilla Foundation morphed into the Mozilla Corporation for tax reasons, Eich eventually landed as MoCo's CTO.

The thing that has the twitter-verse up in arms is Eich's contribution in 2008 to a Pro-Prop-8 organization. For people outside California, Proposition 8 (aka Prop 8) was the "marriage is legally defined in California as being between one man and one woman" proposition that went before the electorate and (somewhat surprisingly) passed. Prop-8 has since been overturned by the courts and all is as it should be.

But there are a lot of us queers in the tech industry and it turns out we have access to political donation rosters (actually, everyone has access to these rosters, they're public information.) And we apparently have reasonably good memories. In 2012 someone noticed the donation and a brouhaha emerged. When Eich was named MoCo's CEO yesterday, the brouhaha re-emerged with some people saying we should boycott Mozilla. Rarebit, for instance, removed their color puzzle app from the Mozilla Marketplace in protest.

In the interests of full disclosure, I worked for MoCo for a brief period of time in 2013 and met Mr. Eich several times. I did not work especially closely with him, nor did we discuss politics. But I had enough encounters to develop this impression: Brendan Eich is a Geek (and I mean that in the good way.) He is, like many in Sili Valley, slightly nerdy, a little more focused on tech subjects than on intra-personal skills. He's not rude, it's just clear he would annoy the living hell out of Emily Post.

I've seen Eich interact with people at MoCo, including people I know he knew were gay. He didn't appear to treat them in any way differently.

And yes, it is troubling to find the CEO of Mozilla's name on a list of people who donated to political causes that sought to deny basic human rights to a minority population. But I personally believe the issue is not so much an issue of homophobia than it is ignorance. I honestly believe Brendan Eich grew up in an environment that reinforced ideas of the moral superiority of "traditional" relationships and he never gave it a second thought.

It would be very nice if Mr. Eich would come out and say something like "Totally sorry about that Prop-8 donation. Upon further reflection, I think it was an inappropriate thing to do." But honestly, I don't think he's under any obligation to do so.

Corporations aren't people, nor are they responsible for the beliefs of their employees. By boycotting Mozilla (the corporation) because one employee did something politically objectionable, you are asking the corporation to police not only the behaviour of it's employees, but also their beliefs. I find Eich's support of Proposition 8 objectionable, but it is more objectionable to ask corporations to deny promotion to individuals who exercise their right to support political efforts outside the corporation.

If you're looking for reasons to hate on Mozilla, there are several to choose from: FirefoxOS' "race to the bottom" strategy, declining market share or questions surrounding the post-2014 funding from Google now that MoCo competes with Android, etc. But having a CEO who thinks my marriage was abhorrent? That's just life in a pluralistic society.

Chapter 3 of my still unnamed Space Vikiing saga

"Hierophant of Discord," Fram said while slapping down his card, "ditch 'em if ya' got 'em!"

An audible sigh came up from Gerstlauer; he had bid blind, not knowing if Fram could cover him.

Gunnr played next, wincing as she threw down the Queen of Discord. She had been saving it to win the next trick and now her plans fell apart. Fram and Gertlauer giggled like kindergartners at the site and broke into full-on laughter as Gert threw down the King of Claw.

"You bid zero with the King of Claw, you have huge balls, my friend!" Wido, the fourth of the card players, cracked at the sight.

Gunnr retorted sourly, "He bid blind. He couldn't have known. His balls are of normal size." The only one of the four to take the loss personally, she complained "come on, let's finish it and get back to work."

"Gunnr, it's just a game. Many days you take us for five times as many points as you lost here," sagt Fram, just becoming aware of her sourness. "But yes, we have three minutes before work resumes. My last two cards are shit," he said, throwing them down face-up on the table leaving Wido and Gerstlauer to argue over who took the last
two tricks.

Gunnr was up and walking back towards her work-station at the forge control. Every bit of her body language screamed tenseness.

Fram caught up with Gunnr, who had already made it several meters from the table. Summoning every bit of grandfatherly softness he could, "what's wrong?"

She waved him away, "Don't try that grandfather business on me! You're not _that_ old," she shot back with surprising venom for someone who had worked with Fram for almost a decade.

It was true Fram wasn't quite old enough to be her grandfather, but could easily be her father. Genetics on the colony were such to make it impossible, of course. But genetics don't stop people from familial attachments; the entire colony would be in a sorry state if it did.

Growing concerned with Gunnr's mood, he tried a different tack, "Gunnr. You have to be here every moment of every day. I won't have you risk injury on my rig 'cause your head is a million miles away."

"No Fram. It's okay. I'm fine." she protested.

Fram was trying to figure out if he had asked her two or three times. Traditions varied amonst the colonists, but all bought into the concept of the heroic self-sufficient individual. Common manners were to deny any sort of help two or three times before admitting you were in need. Fram was old enough to realize what kind of crap this tradition was. He had seen too many people get into too much trouble 'cause they were too proud to let someone help them. The simple fact of the matter was the colony's existence was too tenuous for pride to get in the way of survival.

"Gunnr. I am your work foreman and your friend. I will stay here all day playing stupid manner games, but I will not leave until you tell me what is wrong."

Gunnr leaned in close and whispered a few words in Fram's ear.

All Fram could say in reply was, "Holy shit."

"Yeah," she replied, "you want me here, still?"

"You want to take a day or two off? We're way ahead on our quota, we can manage without you a couple days."

"No Fram, I think I want to be here. Working will take my mind off it." Gunnr replied.

"That's fine. But I want to slow down a bit; no sense tempting fate," Fram said, his eyes darting back and forth the way they do when he's crafting a plan, "Tamsen will ask why we're slowing down though, so let's make up a story of instrument failure or something."

In the eight years Fram had known Gunnr, the hug she gave him was the first time he had know her to do anything even slightly feminine. Taken aback a little, "I love you too, sweetheart," was the only thing he could think to say as he hugged her back.

A Quick Note About the Space Economy

In the last week I've been in a couple very good conversations with people about developing the "space economy." And it's all good; from private launch companies like Orbital and SpaceX to cohorts of enthusiasts willing to die on Mars in the name of exploration and reality television ratings. But there's one thing people have been missing... the space economy isn't about going there and bringing things back, it's about going there, in-situ resource utilization and then staying there a while. 

So it's great when we can launch people to the ISS to research what happens to pumpkin seeds in zero-g, but until they can order a pizza for delivery in LEO, we don't really have a space economy. At best, we have a terrestrial economy with brief forays into orbit. Until we have enough development of non-terrestrial resources that the majority of productive activity is for the benefit of other non-terrestrial development, we're not going to have a space economy.

Just Sayin'.

Using SN-App to Avoid Reinventing the Wheel

Software people who know me know I don't like cut an paste programming. If you can refactor common bits of code out of a program, you probably should. Copying code leads to drudgery and errors if you find you have to change all those places where you hit Ctrl-V. So you can imagine how torked I was at the Node.JS common practice of building new code every time you built a new app. (Granted, it's less common than it used to be, but it's still surprisingly common.)

After the first three connect.js apps I wrote, I refactored the common bits out and made a quick "app runner" that read a config file, used its contents to decide what bits of connect.js middleware to use and then call a different JavaScript module... the one with the "real" code in it. After a couple years of refining, I recently released it as SN-App.

If you use connect.js or express.js, you might find it useful. Rather than writing code to explicitly add commonly used middleware to your Connect or Express app, you build a JSON file listing which bits of middleware you want to load and their parameters. SN-App reads this file and adds the appropriate middleware for you.

Here's a simple SN-App config file. Readers familiar with Connect can probably guess what will happen when it's processed:

properties.json:
{
  "title": "SampleApp",
  "favicon": "static/favicon.ico",
  "static": "static",
  "listen": {
    "port": 80
  }
}

When you execute the SN-App application with the command `sn-app --config file://properties.json`, it loads Connect's "static" middleware to serve static files out of the directory "static" and listens for requests on port 80.

But why use Node if you're just going to serve static files? If you add these lines to the config file, it will turn on the Body Parser middleware and load an additional JavaScript module from src/logic.js:

  "bodyParser": true,
  "source": "src/logic"

And if you're a little lazy, you can ask SN-App to build a skeletal web application for you, complete with a skeletal Bootstrap or Semantic-UI front page. If you wanted to build a simple app to run on port 9001 and served a Semantic-UI index page, just do this:

sn-app-build --title SampleApp --port 9001 --static static \
  --css semanticui
make
sn-app --config file://SampleApp.json

Up and running in seconds flat. If you want to do anything interesting, you'll likely have to edit the SampleApp.json file to do anything interesting, but hey, you were going to do that anyway. SN-App doesn't write the interesting bits for you, it gets the boring bits out of your way so you can get straight to the fun stuff.

Lastly, you can ask SN-App to build a debian init file for you. After running sn-app-build to build the app skeleton and running sn-app to make sure it works, the sn-app-initgen command will generate an init file suitable for inclusion in >/etc/init.d:

sn-app-initgen --name SampleApp --desc "A Sample Application" \
  --dir `pwd` > /etc/init.d/sample
ln -s `which sn-app` SampleApp
chmod 755 /etc/init.d/sample
insserv sample
# Older debians may have to use update-rc.d instead of insserv.

Installing SN-App is pretty straight-forward as well; just use NPM:

sudo npm install -g sn-app

And with that, you're ready to go. For detailed info about properties file options, see the documentation at https://github.com/smithee-us/sn-app - and as always, ping me with questions or comments.

Why I Developed the SN-Props Package for Node.JS

People who know me know I'm a bit of a nut for Node.JS, the JavaScript Application Framework. Over the past several years, I've been writing packages to make developing applications easier. The one that can have immediate utility to virtually all Node developers is SN-Props (fomerly node-props.) On the surface, it looks like a simple package that reads a JSON configuration file from the command-line and passes it to the program shortly after launch. It certainly does do that, but it's even a little more capable, so I figured it would be useful to describe what I was trying to build and the problem I was trying to solve.

In the old days the preferred method of changing the behavior of a program from "Development Mode" to "Production Mode" was via the NODE_ENV environment variable. Before you launched the program, you set this variable to "production" or "development." Inside the program, you would check the environment variable and change your settings appropriately. This led to code that looked like this:

var listen_port;
var listen_addr;
var db_addr;
var db_pass;

if( "production" === process.env.NODE_ENV ) {
  listen_addr = "0.0.0.0";
  listen_port = 80;
  db_addr = "prod-db.example.com";
  db_pass = "DJl87sJXX01";
} else {
  listen_addr = "127.0.0.1";
  listen_port = 8080;
  db_addr = "localhost";
  db_pass = "password";
}

The biggest problem I have with code like this is it makes Node applications brittle. You wind up hard-coding things like database addresses & passwords into the app. If your operations staff needs to change the IP address or password of a machine, you have to track down a developer. And worse -- you wind up committing your database passwords to your source repo.

So the next thing we tried was to read a different JSON configuration file based on the environment variable. That file would contain all your favorite settings in a separate file. During development, you would use the file "dev.json" and in production you would look for "prod.json":

prod.json:

{
  "listen_addr":"0.0.0.0",
  "listen_port": 80,
  "db_addr": "prod-db.example.com",
  "db_pass": "DJl87sJXX01"
}

dev.json:
{
  "listen_addr":"127.0.0.1",
  "listen_port": 8080,
  "db_addr": "localhost",
  "db_pass": "password"
}

This is MUCH better. You no longer have to hard-code config options into the source and your ops staff doesn't have to worry about inadvertently borking production code if they need to change production settings.

At about this time, I started working with "redundant arrays of indepensive web apps." A typical deployment for me would be to have six copies of an app server running simultaneously. And through the magic of virtualization, we would sometimes add an extra two or three servers to meet high-demand periods.

After trying to ensure that exactly the right version of a configuration file made it onto any given server, I realized I wanted was to store my config JSON files on an internal web server. Instead of reading a file on the local file-system for config settings, I just queried the web server. This worked pretty well: I only had to configure one or two files on a single web server to change the behavior of the entire cluster. Yes, I could have used SCP to copy config files, but it was a bit of a pain to program our deploy system to distribute the right file to newly started instances and time it so we pushed the file out before the app started but after the openssh server started. No. It was much better to have the application itself pull it's config data instead of having a central server push the config to new machines.

I was very happy with this solution until we split our app into shards. All of the sudden we needed to have a lot more per-machine config data. Our initial idea was to load up the config server with a bunch of different files, one per machine and make the apps smart enough to pull the right file. This turned out to be annoying due to the large number of config settings that were common to all machines. If you wanted to change a global setting, you had to change the setting in each of the per-machine config files.

The answer was to split our config settings into per-app and per-machine settings. The per machine settings included IP addresses of proxies & sometimes databases. The per app settings included things like tables, usernames and passwords for databases and the like. And after writing a few apps that made two explicit HTTP(S) queries after starting up, it made sense to move that behavior into it's own package.

And that is how the SN-Props was born (though we called it node-props back then.) And this is how I use it today. I put per-machine settings in a local file and per-app or global settings on an internal web server. The per-machine settings file would likely look like this:

{
  "listen": {
    "port": 9001,
    "host": "127.0.0.1"
  },
  "telemetry": "http://west-coast.telemetry.sm5.us/"
}

while the global settings file would look like this:

{
  "appname": "Cookr",
  "tagline": "Crowdfunding innovative recipes since 2014",
  "database": {
    "host": "cookr.db.sm5.us",
    "user": "cookr",
    "password": "DJl87sJXX01",
    "collection": "cookr_main"
  }
}

To start the service, I don't monkey with environment variables, i just create three versions of the various settings files: one for development, another for integration testing and a third for production. When i want to start the app, I list the URLs of the config files on the command line:

/opt/node/bin/node cookr.js --config file:///etc/permachine.json --config http://deploy.int.sm5.us/cookr.json

The SN-Props package is licensed with under a MIT License, so you can use it as well. Here's a code sample of how easy it is to use:

require( 'sn-props' ).read( function( properties ) {
  // Do something with the properties here. The object passed to this
  // function has the contents of all config files merged into it.

} );

Kill. The. Web.

While the world wide web has done a wonderful job of creating inter-operable network applications and distributed data repositories, it has also constrained our thinking about what it means live in a networked society. Despite efforts to make the web "bi-directional" it is still predominantly a one-way publication media.

This needs to change.

"The Web" means everything is reduced to electronic text and graphics that fit in a 960 x 800 array of pixels. This is an acceptable format for reading or even watching videos. Ubiquitous multimedia means we can even listen to music, radio programs or news. Content comes from a server, operated by a single corporate entity, usually a great distance away.

But watch this video excerpt from Adam Curtis "All Watched Over by Machines of Loving Grace:"

Loren Carpenter Experiment at SIGGRAPH '91 from Zachary Murray on Vimeo.

The web, for all its wonders, can't replicate this simple experiment from the early 1990's. The web is about dissolving locality and proximity. To be sure, this is a remarkable achievement. But it's not enough.

We need to think about proximity and closeness.

Not so much because we are social creatures, but because proximity facilitates feedback. The web is not about feedback. EMail, for all it's benefits, does not scale well with increasing numbers of human participants. Intent and meaning dissolve as more people participate in an email thread. Twitter and Facebook have better immediacy, but limitations on content and ownership make them frustrating to use for many tasks. IRC is a collection of text lines; good for many situations, but again, it is frequently difficult to understand why someone is or isn't responding.

Proximity facilitates rich interpersonal communication and rapid feedback.

The web is wonderful, but it was designed to demolish the effects of geographic distribution, not explicitly to support tasks requiring near-immediate feedback. The web doesn't really need to die, but it needs to be supplemented by tools to support meaningful real-time collaboration.

electronic communication for the a-social

I'm not anti-social. I can't be; I have a Klout score that hovers around 50. But lately I've realized I'm ready to leave Twitter and Facebook behind.

I started on computers young. My mom and dad were in the position to put me in front of some of the more innovative, connected computing systems of the early 80's. Dad was a pretty senior tech person in the Air Force and my mom was in education research. And we hit the beginning of the micro-computer revolution perfectly. We were one of those early adopters families; we had a passable home computer and a modem in the summer of '78. Within a year, I discovered I had a second cousin who worked at AT&T and was able to get me an account on an early unix machine (and later, on ATTCTC.) I believe I was the only kid in my 7th grade class writing C programs on Unix.

I feasted on the libertarian culture of the usenet and early BBSes. I remember the day I got my first "real" email account and the joy of having to work out how many bangs people needed to put in it for mail to actually reach me. But here's the thing, the libertarian-democratic ideal of the early internet requires people to behave responsibly, not like entitled ass-hats.

Like everyone else on the early internet, I thought of myself as an advanced individual developing tools to make people's lives better. We were developing technology to cheaply communicate across national borders, enable physically disabled people and making geographic distance irrelevant. The 'net was going to change society for the better. We had a few news groups dedicated to porn, but the vast majority seemed to be about bringing people into the electronic forum and letting them find kindred souls to refine their ideas.

I was on the 'net in September 1993 when the AOL hoard overran the Usenet. Several months in, I was pretty amazed to discover that AOL peeps were, for the most part, not the classless hoard we thought they would be. Things looked good.

But then it started being about money, not people.

Don't get me wrong. I'm not a communist. I have a love-hate relationship with Capitalism, but I'm enough of a bleeding liberal to think we should add some reasonable regulation to the markets. But what happened in the run-up to the dot bomb was pretty sad to see.

Financial markets caught wind of what was going on in Sili Valley and every trader with an AOL account realized where the future was headed. Every business school grad who could spell CPU put together a plan to sell hardware, software or information. Most plans were complete garbage, but what did it matter? Once you get initial funding, you keep going until you can sell a chunk of your company to some other, bigger fool.

Where once we built (mostly) working systems to fit the needs of our users, we were now asked to build incomplete systems that looked plausible. Utility was less important than subscriber growth, because the business people wrote some very nice documents describing how, at any moment, they could convert subscriber growth into income. But why do that now when we still have a little money in the bank; we can optimize our profits by growing as big as we can as fast as we can before we start monetizing.

Everyone knows how this story ends: broken dreams, broken products and more than a few broken marriages. Those who survived licked their wounds and got back to building things. This time around we built things we could sell and we much more cautious about pushing lies about converting eyeballs to money.

But one thing that didn't ever come back... the idea that the user is in control. Sure, the user is the "center" of modern digital systems. But that's because Facebook, Twitter and Google are selling your eyeballs to advertisers. And that's okay as long as we're all honest about what's going on. But slowly we started to see federated identity systems manged by big sites leak information about users to advertisers. And don't get me started about the NSA thing.

So this is what we've become: a network of eyeballs to be sold to purveyors of crap. In the words of Tim Rice's KGB Agent from Chess, we're "prostituting ourselves, chasing a spurious star-light -- trinkets on [web pages] sufficient to lead us astray."

I'm not saying Facebook, Twitter and various Google services aren't without utility. They are quite useful at times. But we're paying too high a price for ubiquity of audience and benign voyeuristic pleasures. I love being able to talk to my relatives on Facebook, but do I really need to see so many animated GIFs of twerking celebrities?

And don't get me started about the tech culture that produced the titstare spectacle. In 1978, Aleksandr Solzhenitsyn observed that the United States was "spiritually weak and mired in vulgar materialism." In 2013, I observe that Solzhenitsyn was an optimist.

So what to do about it?

It's interesting to note that Donald Knuth (whom many consider to be the "father" of algorithm analysis) hasn't had an email account since 1990. One wonders how he is able to renew his driver's license or open a bank account. I envy Dr. Knuth's ability to function without a persistent email mailbox, but I'm not sure I could survive completely without one.

To be sure, I think we could all spend a little less time grooming our inboxes; the zero inbox concept seems patently absurd to me. It simply means you subscribe to no mailing lists and haven't given your email address to marketers.

I think the first thing we may want to consider is limiting how "available" you are. It's the third millennium; an email address is not a novel concept. You derive no social capital simply by being online. You don't have to paste your email address on every web page you produce. Consider using a web-form with a comment box (or heck, put your email address on a gopher server somewhere.) Make it easy for a human to reach you, but hard to communicate your email address to marketers and i suspect you'll have a better email experience.

Consider ignoring email through the day. Look at it once in the evening and/or once in the afternoon. Where I work we use an IRC room to communicate for important things and email to communicate status and not-overly-time-sensitive topics. If you want to kill your productivity, marry yourself to your email account.

Second, go without Facebook or Twitter for a day. I do this from time to time. I've never been a "big" Facebook person to begin with. But try stepping away once in a while. It will be there when you get back.

And lastly, consider starting or joining a "dark" social network. I've been working on these things for a bit. A "dark" social network is one with a fixed membership that is completely undetectable by the public internet. You use a browser to access it, but it doesn't have a welcome and registration screen as much as it has a "NOT FOUND" screen for anyone who doesn't know the right URL.

This isn't so much a security feature as it is an obscurity feature. It's bad to have security by obscurity, but if you actually use "real" security features like strong passwords and TLS along with obscurity, you gain the ability to not have to tell the guy you don't like your account name on this hidden service.

Dark social networks are dark only to the degree everyone in the network keeps the network's existence private. And I think we all know how well our friends keep secrets. So be careful out there; just 'cause something's dark doesn't mean it will stay that way.

One bit of "dark fun" I've been having lately is using obsolete protocols. When was the last time you were on Usenet? or used a Gopher server? Heck, most modern browsers don't even support them anymore.

Now I have to run along and update the contents on my gopher server. Cheers, all!