I’m particularly grateful for the words of Aaron’s partner, Taren Stinebrickner-Kauffman, who closed the service by challenging the technologists in the room with the questions, “If you believe that technology is making the world a better place, why do you believe that? Do you really understand what makes the world a bad place to begin with?” We had already been told that Aaron looked for the worst problems, the most fundamental, and then for the highest-impact solution. Taran’s benediction was a pointed reminder of how different Aaron’s approach was from the norm—that silicon valley made its billions by solving the problems nearest to it. Groceries to your door. Hyperlocal coupons. First-world problems.

Several people talked about Aaron’s comprehensive approach to the problems he encountered. He was a technologist, but he knew that few problems have purely technological solutions. When Aaron began digging at a problem, he saw not a single root, but a rhizome—the vast, hidden network that not only fed that problem but sent up shoots in distant, seemingly unconnected places. Aaron pried at this network, sometimes gently and sometimes clumsily, wherever its roots led.

Aaron tugged at the problem of poverty and found it partly rooted in unequal access to education; he tugged some more and found that fundamental human learning had been enclosed by a conspiracy of the first world’s universities, publishing companies, and for-profit research laboratories. When he pulled a little harder, someone saw him digging in their garden, called the cops, and broke all our hearts.

As our grieving community tries to understand how this happened—how we let this happen—and how we can honor Aaron the the wake of his death, we find the kind of problem that Aaron understood better than most of us. We pry up the injustice of Aaron’s death and trace a root to a bad law, the Computer Fraud and Abuse Act, whose own roots reveal a captured and poorly informed legislature. We trace a different root to an inhumane prosecutor’s office and from there to a plea-bargain system and federal sentencing guidelines that all but guarantee unjust outcomes.

Miserably, we trace all of this back to ourselves, because this brutal system grew out of our own conspiracy of indifference to the least fortunate in our society. Aaron’s hateful prosecution was possible because we ignored the same injustice when it wasn’t happening to the people we know. Because, as Catherine Bracy wrote and several speakers at the memorial said, too few of us followed the roots of our criminal justice process out to the racism and poverty that feed its disproportionate outcomes. Aaron would have, but he’s not here anymore. It’s time for the rest of us to start digging.

Update 1/22: I originally misquoted Taren Stinebrickner-Kauffman slightly (but not substantively).

The New York Tech Meetup is an impressive gathering of the guiding lights (and hopefuls) of the so-called "Silicon Alley" community. With over 27,000 members, NYTM is the largest meetup in the world and has become so influential that it’s attracted guest appearances by New York Mayor Michael Bloomberg and United States CTO Todd Park, and coaxed statements from both 2012 presidential candidates about how their policies will benefit the New York tech community. Every meetup follows a simple format: several New York technology startups present demos of their products and then answer questions from the audience.

NYTM audience members are told there is only one rule about questions: don’t ask about the business model. The stated reason for this is to maintain a focus on tech; the presenters’ business models tend to be familiar—advertising, freemium, etc.—and so aren’t the interesting aspect of their products.

"Don’t ask about the business model" could also be called the founding ethos of this community: what you’re building is the important thing, how you’ll make money is a distant second. Facebook and Twitter didn’t have business models when they built the most popular social networks in the world. IFTTT doesn’t have an obvious business model and it’s the talk of the tech press. With an awesome idea and Series A funding, there’s plenty of time to figure out a business model once you’ve realized your idea.

But "don’t ask about the business model" is beginning to sound like a Freudian slip: Don’t ask, because if you examine the business models too closely, what you find might make you uneasy. We’re far enough into the second dot-boom to see the business models that time and over-reliance on venture funding produce, and there’s plenty of reason for discomfort.

Patents: polluting the software ecology

VC funding, like all free money, isn’t free. Investors are interested in startups not only for their technical excellence but also for their profit potential. They may be willing to give startups without a ready-made business model time to figure one out, but usually only if they believe their investment will be protected until it pays off. And (with few exceptions) that means taking Warren Buffet’s advice and building a "moat" around the business—in most cases, a moat made of patents.

By now, most software developers are aware of the tremendous harm that software patents are causing to the software ecology. Software giants are wasting hundreds of millions of dollars every year suing each other and fending off attacks from patent trolls—holding companies whose sole purpose is to acquire patents and use them to extract royalties from software producers. And while trolls were once mainly concentrated on deep-pocketed players, they increasingly target smaller companies that will go down easy and boost the perceived value of their holdings. As a recent study found, startups fare much worse than established companies in these battles and are likelier to sustain lasting damage or even shut down as a result.

Despite these grave problems, startups feel like they have no choice but to seek patents, because VCs demand it. Maybe they try not to think about it, or maybe they believe they’re not part of the problem, that they’d never use their patents to keep other developers down.

But this misses the point. VCs don’t want their startups to get patents to keep other software companies from beating them to market. A startup’s meager portfolio—at best a handful of patents—won’t deter a troll or stand up against the war chest of a large company like Google or Apple. Even against a smaller competitor, a couple of patents aren’t much use, because the legal fees required to assert them can swallow even a decent Series A round whole.

The truth is that the patents aren’t a moat around the startup’s product, but around the VC’s investment. As every VC knows, a huge proportion of startups fail—as many as 90%. Given this high failure rate, VCs don’t see startups as investments in themselves, but as pieces of an investment portfolio; they’ve placed bets across the board, expecting most of them to lose.

Patents are VCs’ hedge against these inevitable losses. When a startup with patents fails, its patents become the property of its funders, compensation for the unrecouped startup capital. The funders have little use for the patents once the startup that produced them is out of the picture, so the patents become commodities to be sold to the highest bidder. Increasingly, the highest bidders are patent trolls, and the failed startup has inadvertently made the environment for software innovation more radioactive by exactly one (or two or seven) patents.

Strip-mining user data

If 90% of startups fail, then 10% succeed and need a business model to ensure their continued growth after the VC money runs out. Startups without a built-in business model have a few established paths before them: a handful of direct-payment models (pay-per-play, subscription, e-commerce, etc.) and advertising.

Depending on the startup, some of these options are a tough sell. Those that target professional users or businesses can put a price tag on their services without too much grumbling. But social media services (like Twitter and Facebook) and convenience services (like bitly) can typically only attract enough users by starting out free, and users used to free service can rarely be convinced to pay up later. The time-honored solution to this problem is to trade in the currency that users have been paying you all along, but don’t particularly value: their personal information.

Facebook, Twitter, Foursquare: all of the most successful social media services have ultimately balanced their books by ratcheting up their exploitation of users’ data bit by bit. Each gathers an ever-more-detailed profile on every user and sells advertisers the ability to target highly particularized user demographics. Each exploits sharing between users to derive their social networks and learn how information—product preferences, political affiliations, news items—propagates through those networks, all to improve advertising partners’ results.

As with software patents, the problems with commoditizing user data are well-known. The hidden nature of the bargain is problem enough: most users do not fully understand what they’re giving away to these free* services, and fewer still comprehend that merely by tagging their friends or uploading photos of them, they’re giving as much away on behalf of others.

More troubling is the tremendous value of this data to governments eager to understand the social links between persons of interests: terrorists, say, or just troublemakers or dissidents. Facebook and Google, to name just two examples, routinely comply with requests for user data from governments without demanding a warrant. While these problems seem distant to most Western users—at best a concern for criminals here, at worst an unfortunate reality for protesters in Cairo—they’re nonetheless the product of the business models we’re not asking about. And they’re really not so far off, as the US Justice Department demonstrated when it demanded that Twitter turn over private usage data on Americans associated with Wikileaks.

Always ask about the business model

Software patents and data mining are the major ecological issues confronting technologists today. The prevailing business models, far from being uninteresting, have predictable consequences that pollute the environment for innovation and endanger users. Startups that elect these models, either by design or by default, no longer have the luxury of ignoring their inherent ethical problems. We have to start designing for sustainability. We have to ask about the business model. If we don’t, we’re selling out the future of software and the rights of actual human beings.

In yesterday’s New York Times, Ellen Ullman criticized the SEC’s suggestion that mandated software testing could prevent automated-trading catastrophes like the one that shook the market and nearly bankrupted Knight Capital at the beginning of this month. More testing won’t work, according to Ullman, for a few reasons. First, computer systems are too complex to ever “fully test,” because they comprise multiple software and hardware subsystems, some proprietary, others (like routers) containing “inaccessible” embedded code. Second, all code contains bugs, and because bugs can be caused by interactions between modules and even by attempts to fix other bugs, no code will ever be completely bug-free. And finally, it is too difficult to delineate insignificant changes to the software from those that really require testing.

Ullman’s critique of a testing-centric solution has some merit, although few professional developers test individual “coding changes” (they really do test entire systems anytime changes are introduced). But her proposed alternative is heavyweight and difficult to square with the needs of the industry. She proposes making brokers liable for losses caused by trading errors in order to induce them to write “artificial intelligence programs that recognize unusual patterns” and shut down runaway trading algorithms. Her model is the regulation of credit card companies: since they’re liable for most fraudulent charges, they’ve created software to track purchases and put holds on accounts showing suspicious activity. In Ullman’s scheme, the SEC would also create its own electronic sentries as a backstop.

I doubt Ullman’s assumption that the rogue trading program problem can be fought with A.I. as successfully as credit card fraud. The speed of automatic trading—the systems can evaluate and execute thousands of trades per second—makes automated trouble-shooting much trickier. Even very fast A.I. would likely take more than a few seconds to spot bad behavior reliably. This is time enough for several thousand erroneous trades to be made. And false positives would be far more expensive, since for every second the program was down, thousands of legitimate trades would not be made. In the credit card context, where fraud happens at human speed, it makes sense to have humans double-check the computer’s determinations, but Ullman’s suggestion that the same human-backup process would port easily to the algorithmic trading context is ill-considered.

Algorithmic traders could reduce their error rate much less expensively (and more realistically) by collaborating on a common infrastructure for executing trades, using free and open source software everyone could review, test and improve. Trading firms are understandably tight-lipped about the algorithms that actually choose which trades to make; these are the source of their competitive advantage over other firms. But most of the pieces of everyone’s high-frequency trading systems are not so secret, including the real-time operating system, high-volume message queuing, and software actually executing the selected trades. By opening, standardizing, and collaborating on these ancillary but complex components, trading firms could reduce errors and improve reliability, all without exposing their trading strategies. A common infrastructure used and collaboratively produced by several firms would be better-tested than the balkanized systems in use now, and less prone to the interaction effects that Ullman finds prevalent in complex systems. Open code would also enable the SEC to audit the system directly, without the complexity and expense of AI “watchers.”

Doubtless many firms believe their competitive advantage derives partly from proprietary kernel modifications or optimizations to their messaging systems. But the Knight Capital failure, the 2010 Flash Crash, and similar episodes have made it clear that trading firms—as well as their investors and the market as a whole—pay a heavy price for their secrecy. That price will only increase if the SEC passes expensive regulations to deter future failures. If the firms can work together now, they may find that, by turning their infrastructure into shared, standard components, they can not only keep the regulators at bay, but also free their own resources to concentrate on the trading algorithms that are the true value add to their business.

Farro pistachio palm salad

Ingredients

• 1 cup uncooked farro
• 1 head lettuce, chopped (basically anything but iceberg—I used Bibb)
• 2 carrots, julienne
• 3 stalks celery, 1/4″ dice
• 1 can hearts of palm, sliced into 1/4″-thick rounds
• 1/4 cup shelled pistachios
• Juice from 1/2 lemon
• 1 tbsp. oil for dressing (olive, safflower, or whatever you like)
• salt
• pepper

Directions

Bring 4-6 cups of water to boil in a small stockpot. Add the farro, return to a boil, then cover, reduce heat, and simmer for 20-30 minutes, until farro is cooked to desired texture. In the meantime, prepare the vegetables and toss them in a serving bowl. When the farro is done, mix it with the pistachios, lemon, and oil. To the farro mixture, add salt and pepper to taste. Spoon farro mixture over salad and serve.

The process

Cold-Brewed Iced Coffee by thebittenword.com

I did more or less this, although I didn’t bother with the filter-straining step. This was in part because I don’t have filters (my mainstay is an electric percolator) and in part because I was using pre-ground coffee. That last is a fundamental caveat here—my results would likely have been different with high-quality fresh-ground beans.

The results

Cold-brewed coffee does not taste like hot-brewed coffee. I was skeptical of this, because self-identified connoisseurs often blow these things out of proportion. But here the difference is genuine. A coffee-denying friend once told me that the problem with coffee is that it smells wonderful and tastes terrible, and while I either disagree about the taste or am too addicted to care, there’s no doubt that some of the complexity of roasted coffee’s aroma does not show up in the finished hot-brewed product. Much more of that complexity is preserved by cold-brewing. As the article linked above says, the result is a profile like you’d get from quality chocolate or wine: flavors of dried fruits, nuts, cocoa, etc.

So cold-brewed coffee is richer, but I’m not ready to say it’s better. Or, at least, someone who’s used to hot-brewed coffee or even espresso won’t necessarily prefer the flavor of cold-brewed, in the same way that someone used to milk chocolate may find purer chocolate unpalatable. I’ll experiment with some variations and update this with the results.

The artists’ minigolf course has always been one of my favorite parts of Figment and this year I finally got it together to build one of the holes. The theme was “Arcade,” and after a tipsy brainstorming session where Josh suggested a 3D pixel landscape, I decided to build a Super Mario-style hole. My first step was to render the piece in Blender to have images to submit with my proposal and so that I could move pieces around till I got the look I wanted. Here’s the rendering I submitted with the proposal:

The design has changed slightly since, but that’s the basic idea. (Here’s the final blender file, if you’re interested. It betrays my crappy Blender skills.)

The Build

The infrastructure pieces are held together with wood glue. Here's the castle's skeleton drying while Tim checks his pager.

The exterior of the plywood pieces are made of 1.5″ blocks (from craftparts.com). I originally had the fantastically stupid idea of beveling (Tim says I mean “chamfering”) the edges with a belt sander, but once I calculated that I’d need 1,500 hundred of them (times 12 edges per block = 18,000 beveled edges), Tim wisely steered me toward the table saw. He built an absolutely perfect jig (a sort of block tunnel) to guide rows of block over the tilted blade, and we worked out a workflow (cut, flip, rotate, repeat; picture this) that got the job done in about 10 hours, all told. Once the blocks were cut, Kat and Carlydyed them and set them out to dry.

Next, a bunch of us (Anna, Tracy, Carly, Clint, and I) attached the blocks to the plywood structures with Liquid Nails. (For whatever reason, Liquid Nails turned out to be a disaster — when the pieces were subjected to the weather on Governor’s Island, they expanded slightly and the Liquid Nails, having never really fully dried, couldn’t hold them. Most of the blocks had to be reattached with wood glue.)

Here's Tracy and Anna building a blocky hillside.

And here's Carly putting the finishing touches on a hill

Despite this, I took exception to James’s conclusion that “If you appreciate a song or an album buy it so the artist can appreciate your support.” My response (and I’m paraphrasing, because tweets demean us all) was that buying copies of songs is no answer. The great thing about the internet is that we don’t need copies anymore — we can broadcast (relatively, but soon unequivocally) high-quality audio on-demand, instantly, to anyone with a connection. We only ever had to own individual copies of the songs we liked because it was the best technology we had for giving people music on demand, and that’s no longer true. And even though selling copies has been how we’ve primarily paid artists for the last several decades, there must be other ways — we’ve supported musicians for millennia without even being able to record music.

To Sheff, I sounded like all tech people, in no small part because I unwisely called albums “obsolete technology,” which is dismissive and in many ways untrue, to say nothing of its disutility as a rhetorical device in a conversation with a musician. But truly, having a music collection has, for the last several years at least, been nothing but a source of psychological stress for me. I’ve got a small collection of vinyl, because it’s got a physical presence and a mythology that no other format ever did, but I can’t realistically collect music this way, nor can most people — it’s bulky and heavy, and owning very much of it makes rent expensive and moving horrible. CDs truly have nothing to recommend them: none of the mystique of an LP, no perceptibly higher quality than a good mp3, and they still take up lots of space.

So if LPs are impractical and CDs offer no benefits, my remaining option is to “own” some mp3s, but why the hell would I want to do that? Right now I listen to mp3s in three places — my home stereo PC, my laptop that I take to work, and my phone/mp3 player. The collections don’t overlap because my phone doesn’t hold all my music and I don’t sync between my other computers often, so I don’t always have all of my music with me. Worse, hard drives fail like champs, so in addition to all these devices, I’ve got to have a backup if I want to make sure I don’t lose my investment in all those songs I “own.” But even a single-hard drive backup isn’t really reliable, and anyway it takes a lot of discipline to do backups right. If I can subscribe to a service that has all of the songs I want to listen to, I don’t have to worry about storing and moving physical objects, or about backups, or about having all of my music accessible wherever I listen. (Assuming a ubiquitous Internet connection, which is admittedly a big assumption.)

I’m not everybody. Some people have a lot more personally invested in having tangible copies of each of their albums than I do, for example. But whatever gratification they may get out of those physical objects, even they mostly value the music, and an increasing proportion of music fans values only the music. Owning copies adds baggage, not value, for those fans. Telling them to buy a copy is tantamount to asking them to make a donation: it may be the right thing to do, but it’s not really tied in any way to the value they’re getting out of the product, because they’re probably going to listen to the album via the streaming service they were already using.

The point here isn’t that artists should get over it. Music fans need to be aware of how little they’re contributing to the music they love by subscribing to Spotify or Pandora or Rhapsody. But for the artist who can’t count on enlightened, community-minded listeners, the fact remains that people will by and large only pay where they perceive they’re getting value out of the transaction. It’s not good enough that they consider the artist or the art valuable — they have to believe they’re getting specific additional value out of this purchase (to economists, this is “marginal value”). And we’re past the point where most people believe they get any more value out of an mp3 download, a CD, or even an LP, than they do out of reasonably reliable access to a song streaming from someone else’s server.

While I think this is an important thing for artists to understand, I don’t think it’s positive. I think our self-centered insistence on marginal value is the result of centuries of conditioning by capitalism and decades of dependence upon a music production and dissemination system that values profits over art and national/international appeal over intimate (or local) experience. The distribution channels were for many years captured by publishers, leaving independent record stores to struggle along in the margins, and despite the Internet’s promise of connecting fans directly to artists, they’ve only been recaptured as iTunes, Amazon, and the various streaming services. The inevitable national tours, where artists are told to go pick up the slack from album sales, make it impossible for artists to hold down solid jobs, and disconnect them from the local support systems in their hometowns. So the problem’s systemic, and just as it’s not going to be solved by telling people to “buy” albums, it’s not going to be solved by telling artists to just find the money somewhere else.

Do not use the Django admin’s DateTime widget.

I spent the weekend working out how to do a split DateTime widget properly, and I’m pretty happy with the result, so I’ll share it here.  It uses a text field with a jQuery UI calendar picker for the date, and a simple widget for the time.  Here’s what it looks like:

And here’s the code:

To use the field in a form, put something like the following into your form definition:

Finally, you need to put the jQuery UI code somewhere. Go get a custom jQuery UI package (I used all of UI Core and Interactions, the Datepicker widget, and Effects Core — your may want more or less depending on where else you’re using JQuery and JQuery UI), put the necessary files (the jQuery UI css and js, the jQuery js) somewhere accessible to your form. I’m using jQuery UI throughout my site, so I’ve got them in my base.html:

But if you only need jQuery UI for this form, it might make sense to put these in the media class of the JqSplitDateTimeWidget along with jqsplitdatetime.js:

A couple of caveats: this widget is not currently very customizable/internationalizable. It only deals with 12-hour time and I should probably pass the date format in as an argument. But it does the trick for what I need, and what a lot of U.S. developers will need, and these things are easily added (I’d love a patch!).

1. “If you like the widgets that the Django Admin application uses, feel free to use them in your own application! They’re all stored in django.contrib.admin.widgets.” – The Django Form Media documentation

The goals for this application are/were roughly:

• Give developers an easy way to check whether a user has agreed to a particular agreement when the user accesses a view. I decided the best way to do this was through a decorator, like so: @requires_agreement('terms_of_service') def any_old_view(request): ...
• Keep versions of each agreement and record users’ agreement to each, so that the site maintainers have a log of which terms bound a user at which date, and the decorator above can determine whether the user has signed the *latest* version of the agreement.

• When a user is asked to agree to an updated version of an agreement that user has already signed, display a diff of the old form and the current one so that the user can easily see what’s changed.

If you don’t do this, and your site gets big enough, EFF will do it for you. In my opinion, it’s a matter of fundamental respect for users — if you reserve the right in your ToS to make periodic changes to the agreement (and there are good reasons to do this), you should give your users clear notice of those changes.

Unfortunately, the most common practice is to change the terms silently and leave users to seek out a tiny link in the footer if they want to find the current terms. Another common, far better practice is to display the new terms upon the user’s first login to the site after the new terms become active. But few (edit: very few) users read the original terms, much less remember them, so even upon a careful read-through they may have no idea what’s changed. By giving users a diff of the old and new terms, a site makes itself accountable to and builds goodwill with its users. It may also strengthen the legal effect of its terms by giving users actual notice (although courts have been all too ready to enforce online agreements with little to no notice).

I’ve been working on developing a free software application market for Android.¹ The obvious place to start was the SlideME Community Edition code, which as far as I know is the only existing free software project that does even part of the job. Unfortunately, SlideME’s Community Edition was abandoned due to “lack of community interest” in April 2008, several months before the first Android phones were even available. So most of the work I’ve done so far was to update the code to work with the current SDK, rework the interface to behave in a more standard way, and rewrite portions that relied on now-unavailable API elements.

FLOSS Dispenser (like SlideME) works in conjunction with a J2EE server application called JVending. JVending’s public repository was also abandoned by SlideME some time ago, so I’m maintaining a fork of JVending along with my fork of FLOSS Dispenser as a part of the Replicant project.

I put up build instructions for FLOSS Dispenser as well as for JVending; using these, you should be able to build both and have them work together. However, neither one is ready, which is why I’m not hosting an application store already. The FLOSS Dispenser code in particular is pretty buggy (most of them aren’t mine, but only because I haven’t written much of it), for one thing. For another, the system doesn’t yet facilitate GPL compliance — you can download and install apk binaries, but they don’t come with source code and license text. Until at least this feature exists, I don’t recommend anyone serve GPL’d apks to the public using JVending. Update: The client application is now in a working alpha state. The really bad bugs have been hammered out and source can be delivered with the apk (the mechanism for this is nonoptimal, but functional). The challenge now is to enable users of the server to submit new apps easily, and to enable admins to moderate them.

I wanted to have this and some other issues hammered out before I put the code up, but I was motivated by Jonathan Corbet’s recent LWN article on Android to just put up what I had and try to get some help. I know other people are interested in something like this, and though I’m hardly proud of the little coding I’ve done on this, it’s the best start we have for a free market.

So by all means, take a look and help me kick this thing out the door.

1. The quick rationale for this is that the Android Market 1) is not itself free software, and 2) doesn’t enable you to search for applications by their license.