Cogito, Ergo Sumana

Categories: sumana | Deliverables

Announcements of things I have made, like zines, software, and articles on other websites.


: On LiveJournal: I've posted to MetaFilter about some recent goings-on at LiveJournal; if you have an LJ account you should probably take a look.

Filed under:


: New Zine "Playing With Python: Two of My Favorite Lenses":

half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen, on a wooden table that also has a mug and a laptop on it

MergeSort, the feminist maker meetup I co-organize, had a table at Maker Faire earlier this month. Last year we'd given away (and taught people how to cut and fold) a few of my zines, and people enjoyed that. A week before Maker Faire this year, I was attempting to nap when I was struck with the conviction that I ought to make a Python zine to give out this year.

So I did! Below is Playing with Python: 2 of my favorite lenses. (As you can see from the photos of the drafting process, I thought about mentioning pdb, various cool libraries, and other great parts of the Python ecology, but narrowed my focus to bpython and python -i.)

Zine cover; transcription below

Playing with Python
2 of my favorite lenses
[magnifying glass and eyeglass icons]

by Sumana Harihareswara

Second and third pages of zine; transcription below

When I'm getting a Python program running for the 1st time, playing around & lightly sketching or prototyping to figure out what I want to do, I [heart]:
bpython & python -i

[illustrations: sketch of a house, outline of a house in dots]

Fourth and fifth pages of zine; transcription below

bpython is an exploratory Python interpreter. It shows what you can do with an object:

>>> dogs = ["Fido", "Toto"]
>>> dogs.
append count extend index insert pop remove reverse sort

And, you can use Control-R to undo!
bpython-interpreter.org

[illustrations: bpython logo, pointer to cursor after dogs.]

Sixth and seventh pages of zine; transcription below

Use the -i flag when running a script, and when it finishes or crashes, you'll get an interactive Python session so you can inspect the state of your program at that moment!

$ python -i example.py
Traceback (most recent call last):
    File "example.py", line 5, in 
        toprint = varname + "entries"
TypeError: unsupported operand type(s) for + : 'int' and 'str'
>>> varname
3
>>> type(varname)

[illustration: pointer to type(varname) asking, "wanna make a guess?"]

Back cover of zine; transcription below

More: "A Few Python Tips"
harihareswara.net/talks.html
This zine made in honor of
MergeSort
NYC's feminist makerspace!
http://mergesort.nyc

CC BY-SA 2016 Sumana Harihareswara
harihareswara.net @brainwane

Everyone has something to teach;
everyone has something to learn.

Laptop displaying bpython logo next to half-scratched-out bpython logo, Python code, and technical prose written and drawn on paper, with notebook and pen and mug, on a wooden table

Here's the directory that contains those thumbnails, plus a PDF to print out and turn into an eight-page booklet with one center cut and a bit of folding. That directory also contains a screenshot of the bpython logo with a grid overlaid, in case you ever want to hand-draw it. Hand-drawing the bpython logo was the hardest thing about making this zine (beating "fitting a sample error message into the width allotted" by a narrow margin).

Libby Horacek and Anne DeCusatis not only volunteered at the MergeSort table -- they also created zines right there and then! (Libby, Anne.) The software zine heritage of The Whole Earth Software Review, 2600, BubbleSort, Julia Evans, The Recompiler, et alia continues!

(I know about bpython and python -i because I learned about them at the Recurse Center. Want to become a better programmer? Join the Recurse Center!)

Filed under:


: iCalendar Munging with Python 3, Requests, ics.py, and Beautiful Soup: Leonard and I love seeing movies at the Museum of the Moving Image. Every few months we look at the calendar of upcoming films and decide what we'd possibly like to see together, and put it on our shared calendar so we remember. And for every showing (example) the MoMI provides an iCalendar (.ics) file, to help you add it to your electronic calendar. But it's a pain to individually download or refer to each event's .ics file and import it into my electronic calendar -- and the museum's .ics files' DTEND times are often misleading and imply that the event has a duration of 0 seconds. (I've asked them to fix it, and some of their calendar files have correct durations, but some still have DTEND at the same time as DTSTART.)

Saturday morning I had started individually messing with 30+ events, because the MoMI is doing a complete retrospective of Krzysztof Kieslowski's films and I am inwardly bouncing up and down with joyous anticipation about seeing Dekalog again. And then I thought: I bet I can automate some of this tedious labor!

bash terminal showing the successful output of a Python script (a list of movie titles and "Calendar ready for importing: MoMI-movies-chosen-2016-09-26.ics") So I did. The create-fixed-ics.py script (Python 3) takes a plain text file of URLs separated by newlines (see movie-urls-sample-file.txt for an example), downloads iCalendar files from the MoMI site, fixes their event end times, and creates a new unified .ics file ready for import into a calendar. Perhaps the messiest bit is how I use a set of regular expressions, and my observations of the customs of MoMI curators, to figure out the probable duration of the event.

Disclaimers:

Much thanks to the programming ecology that helped me build this, especially the people who made RegExr, Beautiful Soup (hi Leonard), Requests, ics.py, and the bpython interpreter, and the many who have written excellent documentation on Python's standard library. Thanks also to Christine Spang, whose "Email as Distributed Protocol Transport: How Meeting Invites Work and Ideas for the Future" talk at Open Source Bridge 2015 (video) introduced me to hacking with the iCalendar format.
Filed under:


: New Essay: "Toward a !!Con Aesthetic": Over at The Recompiler, I have a new essay out: "Toward A !!Con Aesthetic". I talk about (what I consider to be) the countercultural tech conference !!Con, which focuses on "the joy, excitement, and surprise of programming". If you're interested in hospitality and inclusion in tech conferences -- not just in event management but in talks, structure, and themes -- check it out.

Christie Koehler also interviews me about this and about activist role models, my new consulting business, different learning approaches, and more in the latest Recompiler podcast.

[announcement cross-posted from Geek Feminism]

Filed under:


: What Is Maintainership?: Yesterday, at my first LibrePlanet conference, I delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I spoke without a script, and what follows is what I meant to say; I hope it bears a strong resemblance to what I actually said. I do not know whether any video of this session will appear online; if it does, I'll update this entry.

What is Maintainership?

Or, approaches to filling management skill gaps in free software

Sumana Harihareswara, Changeset Consulting
LibrePlanet, Cambridge, MA, 20 March 2016

Why do we have maintainers in free software projects? There are various different explanations you can use, and they affect how you do the job of maintainer, how you treat maintainers, how and whether you recruit and mentor them, and so on.

So here are three -- they aren't the only ways people think about maintainership, but these are three I have noticed, and I have given them alliterative names to make it easier to think about and remember them.

Sad: This is a narrative where even having maintainers is, fundamentally, an admission of failure. Jefferson said a lot of BS, but one thing he said that wasn't was: "If men were angels, we would have no need of government." And if every contributor contributed equally to bug triage, release management, communication, and so on, then we wouldn't need to delegate that responsibility to someone, to a maintainer. But it's not like that, so we do. It's an approach to preventing the Tragedy of the Commons.

I am not saying that this approach is wrong. It's totally legitimate if this is how you are thinking about maintainership. But it's going to affect how your community does it, so, just be aware.

Skill: This approach says, well, people want to grow their skills. This is really natural. People want to get better, they want to achieve mastery, and they want validation of their mastery, they want other people to respect their mastery. And the skill of being a maintainer, it's a skill, or a set of skills, around release management, communication, writing, leadership, and so on. And if it's a skill, then you can learn it. We can mentor new maintainers, teach them the skills they need.

So in this approach, people might have ambition to be maintainers. And ambition is not a dirty word. As Dr. Anna Fels puts it in her book Necessary Dreams, ambition is the combination of the urge to achieve mastery of some domain and the desire to have your peers, or people you admire, acknowledge, recognize, validate your mastery.

With this skills approach, we say, yeah, it's natural that some people have ambition to get better as developers and also to get better at the skills involved in being a maintainer, and we create pathways for that.

Sustain: OK, now we're talking about the economics of free software, how it gets sustained. If we're talking about economics, then we're talking about suppply and demand. And I believe that, in free software right now, there is an oversupply of developers who want to write feature code, relative to an undersupply of people with the temperament and skills and desire to do everything else that needs doing, to get free software polished and usable and delivered and making a difference. This is because of a lot of factors, who we've kept out and who got drawn into the community over the years, but anyway, it means we don't have enough people who currently have the skill and interest and time to do tasks that maintainers do.

But we have all these companies, right? Companies that depend on, that are built on free software infrastructure. How can those with more money than time help solve this problem?

[insert Changeset Consulting plug here]. You can hire my firm, Changeset Consulting, to do these tasks for a free software project you care about. Changeset Consulting can do bug triage, doc rewriting, user experience research, contributor outreach, release management, customer service, and basically all the tasks involved in maintainership except for the writing and reviewing of feature code, which is what those core developers want to be doing anyway. It's maintainer-as-a-service.

Of course you don't have to hire me. But it is worth thinking about what needs to be done, and disaggregating it and seeing what bits companies can pay for, to help sustain the free software ecology they depend on.

So: sad, skill, sustain. I hope thinking about what approach you are taking helps your project think about maintainership, and what it needs to do to make the biggest long-term impact on software freedom. Thank you.

Filed under:


: What Should We Stop Doing? (FLOSS Community Metrics Meeting keynote): "What should we stop doing?": written version of a keynote address by Sumana Harihareswara, delivered at the FLOSS Community Metrics Meeting just before FOSDEM, 29 January 2016 in Brussels, Belgium. Slide deck is a 14-page PDF. Video is available. The notes I used when I delivered the talk were quite skeletal, so the talk I delivered varied substantially on the sentence level, but covered all the same points.

Photo of me at FLOSS Metrics meeting, public domain by ben van't ende, https://photos.google.com/share/AF1QipMGh90Jfl8uVKH3U-e4CGF93i-vbHvhjbWVOvkn3ZlOeBAoc5PX_n_augA9v-cvPQ/photo/AF1QipNmQJdbqw2TrhcX6HuooqUuQmLfFbRkn73QW_Aq?key=NXFqUUVqdlN6MWdQSFdSNEFBSVFKajRpQVVQNnpnI'd like to start with a story, about my excellent boss I worked for when I was at the Wikimedia Foundation, Rob Lanphier, and what he told me when I'd been on the job about eight months. In one of our one-on-one meetings, I mentioned to him that I felt overwhelmed. And first, he told me that I'd been on the job less than a year, and it takes a year to ramp up fully in that job, so I shouldn't be too worried. And then he reminded me that we were in an amazing position, that we would hear and get all kinds of great ideas, but that in order to get anything done, we would have to focus. We'd have to learn to say, "That's a great idea, and we're not doing it." And say it often. And, he reminded me, I felt overwhelmed because I actually had the power to make choices, about what I did with my time, that would affect a lot of people. I was not just cog # 15,000 doing a super specialized task at Apple.

So today I want to talk with you about how to use the power you have, in your open source projects and organizations, and about saying no to a lot of things, so you can focus on doing fewer things well -- the Unix philosophy, right? I'll talk about a few tools and leave you with some questions.

Tool 1: Remember to say no to the lamppost fallacy

The lamppost fallacy is an old one, and the story goes that a drunk guy says, "I dropped my keys, will you help me look for them?" "OK, sure. Where'd you drop them?" "Under that tree." "So why are you looking for them under this lamppost?" "Well, the light is better here."

A. Quantitative vs qualitative in the dev data

The first place we ought to check for the lamppost fallacy is in overvaluing quantitative metrics over qualitative analysis when looking at developer workflow and experience. Dave Neary said, in the FLOSSMetrics meeting in 2014, in "What you measure is what you get. Stories of metrics gone wrong": Use qualitative and quantitative analysis to interpret metrics.

When it comes to developer experience, you can be analytical while both quantitative and qualitative. And you rather have to be, because as soon as you start uncovering numbers, you start asking why they are what they are and what could be done to change that, and that's where the qualitative analytical approach comes in.

Qualitative is still analytical! Camille Fournier's post, "Qualitative or quantitative but always analytical", goes into this:

qualitative is still analytical. You may not be able to use data-driven reasoning because you're starting something new, and there are no numbers. It is hard to do quantitative analysis without data, and new things only have secondary data about potential and markets, they do not have primary data about the actual user engagement with the unbuilt product that you can measure. Furthermore, even when the thing is released, you probably have nothing but "small" data for a while. If you only have a thousand people engaging with something, it is hard to do interesting and statistically significant A/B tests unless you change things drastically and cause massive behavioral changes.

This is applicable to developer experience as well!

For help, I recommend the Wikimedia movement's Grants Evaluation & Learning team's table discussing quantitative and qualitative approaches you can take: ethnography, case studies, participant observation, and so on. To deepen understanding. It's complementary with the quantitative side, which is about generalizing findings.

B. Quantifiable dev artifacts-and-process data versus data about everything else

Another place to check for the lamppost fallacy is in overvaluing quantifiable data about programming artifacts and process over all sorts of data about everything else that matters about your project. Earlier today, Jesus González-Barahona mentioned the many communities -- dev, contributor, user, larger ecosystem -- that you might want to research. There's lots of easily quantifiable data about development, yes, but what is actually important to your project? Dev, user, sysadmin, larger ecology -- all of these might be, honestly, more important to the success of your mission. And we also know some things about how to get better at getting user data.

For help, I recommend the Simply Secure guides on doing qualitative UX research, such as seeing how users are using your product/application. And I recommend you read existing research on software engineering, like the findings in Making Software: What Really Works and Why We Believe It, the O'Reilly book edited by Andy Oram and Greg Wilson.

Tool 2: know what kind of assessment you're trying to do and how it plays into your theory of change

Another really important tool that will help you say no to some things and yes to others is knowing what kind of assessment you're trying to make, and how that plays into your hypothesis, your theory of change.

I'm going to mess this up compared to a serious education researcher, but it's worth knowing the basics of the difference between formative and summative assessments.

Formative assessment or evaluation is diagnostic, and you should use it iteratively to make better decisions to help students learn with better instruction & processes.

Summative assessment is checking outcomes at the conclusion of an exercise or a course, often for accountability, and judging the worth/value of that educational intervention. In our context as open source community managers, this often means that this data is used to persuade bosses & community that we're doing a good job or that someone else is doing a bad job.

As Dawn Foster last year said in her "Your Metrics Strategy" speech at the FLOSSMetrics meeting:

METRICS ARE USEFUL Measure progress, spot trends and recognize contributors.
Start with goals: WHY FOCUS ON GOALS? Avoid a mess: measure the right things, encourage good behavior.

Here's Ioana Chiorean, FLOSS Community Metrics meeting, January 30th 2015, "How metrics motivate":

Measure the right things... specific goals that will contribute to your organization's success

Dave Neary in 2014 in "What you measure is what you get. Stories of metrics gone wrong" at the Metrics meeting said:

be careful what you measure: metrics create incentives
Focus on business and community's success measurements

And this is tough. Because it can be hard to really make a space for truly formative assessment, especially if you are doing everything transparently, because as soon as you gather and publish any data, people will use it to argue that we ought to make drastic changes, not just iterative changes. But it might help to remember what you are truly aiming at, what kind of evaluation you really mean to be doing.

And it helps a lot to know your Theory of Change. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B.

There's a chicken and egg problem here. How do you form the hypothesis without doing some initial measurement? And my perhaps subversive answer is, use ideas from other communities and research to create a hypothesis, and then set up some experiments to check it. Or go with your gut, your instinct about what the hypothesis is, and be ready to discard it if the data does not bear it out.

For help: Check out educational psychology, such as cognitive apprenticeship theory - Mel Chua's presentation here gives you the basics. You might also check out the Program/Grant Learning & Evaluation findings from Wikimedia, and try out how the "pirate metrics" funnel -- Acquisition, Activation, Retention, Referral, Revenue, or AARRR -- fits with your community's needs and bottlenecks.

Tool 3: if something doesn't work, acknowledge it

And the third tool is that when we see data saying that something does not work, we need to have the courage to acknowledge what the data is saying. You can move the goalposts, or you can say no and cause some temporary pain. We have to be willing to take bug reports.

Here's an example. The Wikimedia movement likes to host editathons, where a bunch of people get together and learn to edit Wikipedia together. We hoped that would be a way to train and retain new editors. But Wikipedia editathons don't produce new long-term editors. We learned:

About 52% of participants identified as new users made at least one edit one month after their event, but the percentage editing dropped to 15% in the sixth months after their event

And, in "What we learned from the English Wikipedia new editor pilot in the Philippines":

Inviting contribution by surfacing geo-targeted article stubs was not enough to motivate or help users to make their first edits to an article. Together, all new editors who joined made only six edits in total to the article space during this experiment, and they made no edits to the articles we suggested.

Providing suggestions via links to places users might go for help did not appear to sufficiently support or motivate these new editors to get involved. 50 percent of those surveyed later said they didn’t look for help pages. Those who did view help pages nevertheless did not edit the suggested articles.

But over and over in the Wikimedia movement I see that we keep hosting those one-off editathons. And they do work to, for instance, add new high-quality content about the topics they focus on, and some people really like them as parties and morale boosters, and I've heard the argument that they at least get a lot of people through that first step, of creating an account and making their first edit. But that does not mean that they're things we should be spending time on, to reverse the editor decline trend. We need to be honest about that.

It can be hard to give up things we like doing, things we think are good ideas and that ought to work. As an example: I am very much in favor of mentorship and apprenticeship programs in open source, like Google Summer of Code and Outreachy. Recently some researchers, Adriaan Labuschagne and Reid Holmes, raised questions about mentorship programs in "Do Onboarding Programs Work?", published in 2015, about whether these kinds of mentorship programs move the needle enough in the long run, to bring new contributors in. It's not conclusive, but there are questions. And I need to pay attention to that kind of research and be willing to change my recommendations based on what actually works.

We can run into cognitive dissonance if we realize that we did something that wasn't actually effective. Why did I do this thing? why did we do this thing? There's an urge to rationalize it. The Wikimedia FailFest & Learning Pattern hackathon 2015 recommends that we try framing our stories about our past mistakes to avoid that temptation.

Big 'F' failure framing:
  1. We planned this thing: __________________________
  2. This is how we knew it wasn't working: __________________________
  3. There might have been some issues with our assumption that: __________________________
  4. If we tried it again, we might change: __________________________

Little 'f' failure framing:

  1. We planned this thing: __________________________
  2. This is how we knew it wasn't working: __________________________
  3. We think that this went wrong: __________________________
  4. Here is how to fix it: __________________________

For help with this tool, I suggest reading existing research evaluating what works in FLOSS and open culture, like "Measuring Engagement: Recommendations from Audit and Analytics" by David Eaves, Adam Lofting, Pierros Papadeas, Peter Loewen of Mozilla.

Priorities

I have a much larger question to leave you with.

One trend I see underlying a big chunk of FLOSS metrics work is the desire to automate the emotional labor involved in maintainership, like figuring out how our fellow contributors are doing, making choices about where to spend mentorship time, and tracking a community's emotional tenor. But is that appropriate? What if we switched our assumptions around and used our metrics to figure out what we're spending time on more generally, and tried to find low-value programming work we could stop doing? What tools would support this, and what scenarios could play out?

This is a huge question and I have barely scratched the surface, but I would love to hear your thoughts. Thank you.

Sumana Harihareswara, Changeset Consulting

Filed under:


: Comparing Codes of Conduct to Copyleft Licenses (My FOSDEM Speech): "Comparing codes of conduct to copyleft licenses": written notes for a talk by Sumana Harihareswara, delivered in the Legal and Policy Issues DevRoom at FOSDEM, 31 January 2016 in Brussels, Belgium. Video recording available. Condensed notes available at Anjana Sofia Vakil's blog.

FOSDEM logo Good afternoon. I'm Sumana Harihareswara, and I represent myself, and my firm Changeset Consulting. I'm here to discuss some things we can learn from comparing antiharassment policies, or community codes of conduct, to copyleft software licenses such as the GPL. I'll be laying out some major similarities and differences, especially delving into how these different approaches give us insight about common community attitudes and assumptions. And I'll lay out some lessons we can apply as we consider and advocate various sides of these issues, and potentially to apply to some other topics within free and open source software as well.

My notes will all be available online after this, so you don't have to scramble to write down my brilliant insights, or, more likely, links. And I don't have any slides. If you really need slides, I'm sorry, and if you're like, YES! then just bask in the next twenty-five minutes.

I. Credibility

I will briefly mention my credentials in speaking about this topic, especially since this is my first FOSDEM and many of you don't know me. I have been a participant in free and open source software communities since the late 1990s. I'm the past community manager for MediaWiki, and while at the Wikimedia Foundation, I proposed and implemented our code of conduct, which we call a Friendly Space Policy, for in-person Wikimedia technical spaces such as hackathons and conferences.

I wrote an essay about this topic last year, as a guest post on the social sciences group blog Crooked Timber, and received many thoughtful comments, some of which I'll be citing in this talk.

I am also a contributor to several GPL'd pieces of code, such as MediaWiki and GNU Mailman, on code and non-code levels. And I am the creator of Randomized Dystopia, a GPL'd web application that helps you in case you want to write scifi novels about new dystopian tyrannies that abrogate different rights.

And I have been flamed for suggesting codes of conduct; for instance, one Crooked Timber commenter called me "a wannabe politician, trying to find a way to become important by peddling solutions to non-problems." Which is not as bad as when one person replied to me on a public mailing list and said, "Deja Vue all over again. I finally understand why mankind has been plagued by war throughout its entire history...." So maybe I'm the cause of all wars in human history. But I probably won't be able to cover that today.

II. The basic comparison

So let's start with a basic "theory of change" lens. When you're an activist trying to make change in the world, whether it's via a boycott, a new app, a training session, founding an organization, or some other approach, you have a theory of change, whether it's explicit or implicit. You have an assessment of the way the world is, a vision of how you want the world to look, and a hypothesis about some change you could make, an activity or intervention you could perform to move us closer from A to B. There's a pretty common theory of change among copyleft advocates and a couple of theories of change that are common to code of conduct advocates.

A. GPL

The GPL restricts some software developers' freedom (around redistributing software and around adding code under an incompatible license) so as to protect all users' freedom to use, inspect, modify, and hack on software.

The copyleft theory of change supposes that more people will be more free if we can see, modify, and share the source code to software we depend on, and so it's worth it to prohibit enclosure-style private takeovers of formerly shared code. Because in the long run, this will enable free software developers to build on each others' work, and incentivize other developers to choose to make their software free.

B. Codes of Conduct

Now, codes of conduct, antiharassment policies, friendly space policies: They restrict some people's behavior and require certain kinds of contributions from beneficiaries, so as to increase everyone's capabilities and freedom in the long run.

One pretty popular theory of change goes like this: we will make better software and have a greater impact if more people, and more different kinds of people, find our communities more appealing to work in. One thing making an unpleasant environment and driving away contributors, especially contributors with perspectives that are underrepresented in our communities, is hurtful misbehavior in community spaces. So we'll make the trade and say that it's worth it to restrict some behavior, in order to make the environment better so more, and more varied, people can do work in our communities, and thus make more free software and make it better.

And here's another related one, very similar to the one above, but focusing on the day-to-day freedom of community participants who are marginalized. If the constraint stopping me from, for instance, speaking in an IRC channel is that I strongly suspect I'll be harassed if they know I'm a woman, and that I don't have any reason to believe I can avoid or usefully complain about that harassment, how free am I to participate in that community? Is there perhaps a way to understand a certain level of safety as a necessary prerequisite to liberty?

I realize that this is probably the one room in the world where I have the highest chance to getting into a multi-hour "what does freedom mean" bikeshedding session, so I'm going to avoid focusing on the second model there and focus more on the first one, which emphasizes the end result of more free software.

Photo of me at FOSDEM 2016, CC BY-SA Luis García Castro, https://twitter.com/luiyo/status/700938185115836416

C. Assumptions

So I am not assuming that everyone in this room is a copyleft advocate, but I am going to assume from this point forward that we in this room fundamentally understand the restrictive license argument, that we have a handle on the theory of change that it's operating on. And similarly, I'm sure there are people here who aren't so big on codes of conduct, but I'm going to assume that we fundamentally understand the theory of change behind that approach, regardless.

D. Similarities

Now let's talk about similarities. Chris Webber calls both of these approaches "added process which define (and provide enforcement mechanisms for) doing the right thing." I agree. Without this kind of gatekeeping we see free rider incentives, on other people's software work and on other people's attention and patience and emotional labor.

They are written-down formalizations of practices and values that some community members think should be so intuitive and obvious that asking people to formally offer or accept the contract is an insult, or at least an unnecessary inconvenience. And so some people counterpropose sort-of-humorous policies, such as the "Do What the Fuck You Want to" software license and "don't be a jerk" codes of conduct.

They are loci of debate and fragmentation.

Some people agree to them thoughtfully, some agree distractedly as they would to corporate clickthrough EULAs, some disagree but click through anyway (acting in bad faith), some disagree and silently leave, some disagree and negotiate publicly, some disagree and fork publicly. Some people won't show up if the agreement is mandatory; some people won't show up UNLESS it's mandatory; some people don't care either way. And, by the way, good community management requires properly predicting the proportions, and navigating accordingly.

Both copyleft licenses and codes of conduct are approaches to solving problems that became more apparent along with different people realizing they have different expectations and needs, and consider different outcomes or processes to be "fair."

These kinds of codes and licenses usually cover specific bounded events and spaces or sites, and their scope covers interpersonal or public interactions. Codes of conduct usually dont cover conversations outside community-run spaces or the beliefs you hold in your head; open source licenses' restrictions usually kick in on redistribution, not use, so they don't constrain anything you do only on your own computer.

Neither one of these approaches can rely on self-enforcement. There is some self-enforcement of both, of course. There's a perception that -- as Harald K. commented on my blog post -- "licenses more or less police themselves (or in extreme instances, are policed by outsiders) whereas codes of conduct need an internal governing structure, a new arena where political power can be exercised." My personal understanding, which I share with people like Matthew Garrett, is that there's a ton of license-breaking happening, and we need to support existing organizations like the Software Freedom Conservancy to police that misbehavior and litigate to defend the GPL. As Conservancy head Karen Sandler points out in her December essay "From a lawyer who hates litigation", "I've seen companies abuse rights granted to them under the GPL over and over again. As the years pass, it seems that more and more of them want to walk as close to the edge of infringement as they can, and some flagrantly adopt a catch-me-if-you-can attitude." And you see enough individuals in our communities acting similarly that I don't think I need to belabor this point; codes of conduct are much more productive when they're actually, you know, enforced.

And both copyleft licenses and codes of conduct restrict freedom regarding certain acts, over and above what is restricted by the law, in the interest of a long-term good, which can in both cases be construed as greater freedom. As Belle Waring says to one skeptic in the Crooked Timber comments, paraphrasing their argument: "part of your reasonable resentment is, 'I don't want to be forced to do freedom-restricting things in support of a very uncertain outcome, just because the final proposed outcome is a good one.'" I will go into that bit of argument later.

E. Differences

But these kinds of agreements are different on a few different axes, which I think are worth considering for what they tell us about open stuff community values and about our intuitions on what kinds of freedom restrictions we find easier to accept.

One is that many codes of conduct focus on in-person events such as conferences, rather than online interactions. Many of the unpleasant incidents that caused communities to adopt CoCs -- or that communities see as "let's not let that happen here" warning bells -- happen at face-to-face events. And face-to-face spaces have a much longer history and context of ways of dealing with bad behavior than do online spaces. After all, a pretty widespread reading of the core function of government and law enforcement is that they keep Us Good Guys safe by stopping The Bad Guys from committing face-to-face (or knife-to-face or chair-to-face) assault.

But there's another axis I want to explore here: whether the behavior constraint feels like a contract or whether it feels like governance. Of course, we toss around phrases like "the social contract" and use the metaphor of contract to talk about the legitimacy of government, but to an ordinary citizen, contracts and governance feel like significantly different things. To oversimplify: to a non-lawyer like me, something that feels like a contract formalizes a specific trade, something discrete and finite and a bit rare. A copyleft license feels that way to me; it specifies that if I distribute a certain artifact -- which is something I would only do after some amount of thought and work -- I then also undertake certain obligations, namely, I must also redistribute the software's source code, under the same license. And, notwithstanding edge cases, it is often easy to examine the artifact, follow a decision procedure, and determine that I have complied with the terms of the license. If I meant to comply in the first place.

On the other hand, when we make rules constraining acts, especially speech acts, it feels more like governance.

Codes of conduct serve as part of a community's infrastructure to fulfill the first duty of a government — to protect its citizens from harm — and in order to make them work, communities must develop governance processes. That is to say, "governance" is what we call it when we're explicit about who gets to make and implement rules that affect everyone in a community, and how we choose those people or get rid of them. And a governance body does not necessarily have to be a legal entity. For instance, in MediaWiki governance, there's an architecture committee that decides on large technical architectural changes, and it has no standing in the eyes of the United States government.

It takes work to evaluate whether actions have complied with rules, and that work might require asking questions of suspects, bystanders, and targets. Enforcing a code of conduct, even a narrowly scoped anti-harassment policy, often requires that someone act on behalf of a community to do this, and to implement the outcome -- be it informed by retributive, rehabilitative, transformative, or some other justice model. And it feels more like governance than contract to me if a rule applies to actions I take many times a day without deliberate planning -- such as saying something in my project's live internet chat room.

One way of thinking about this is: is there some kind of authority that the community acknowledges as having legitimate power over everyday behavior, over and above existing government with a capital G? Because, again, licenses affect certain coding and architectural decisions, but they don't preclude, for instance, everyday discussion. In fact, the social and digital infrastructure it takes to make robust and usable software, including our bug reports, our automated tests, our conversation on mailing lists, and so on, is often not covered by any particular open license -- if it were, maybe we'd be seeing a different level of pushback even from developers who are happy with copyleft as applied to their code.

F. Shortcomings of the contract model

But I think another interesting thing that happens when you compare a governance model to a contract model, regarding approaches we take to improving behavior in our communities, is seeing how governance wins. It takes a lot of work, but it has a lot of advantages.

1. Flexibility

Contracts are binary where ongoing dialogue and governance can be more flexible and responsive. If I were going to be really annoying I would compare them to compiled bytecode and to interpretable scripts. Contracts have to sort of self-contain the tests for what the contract permits, mandates, and prohibits, whereas governance mechanisms and bodies can use more general standards, which might change over time. To quote one of the commenters on my essay, Stephenson-quoter kun:

contracts explicitly restrict acts which are simply unpardonable -- not sharing the source code to your modified version of a GPL-licensed project, sexually assaulting someone at a conference -- because everyone agrees that those things are wrong and we feel confident that we can agree up-front that there can never be any extenuating circumstances in which those things are actually OK. Governance, however, can serve to 'nudge' people away from bad behaviours – poor coding standards, rudeness on mailing lists -- by giving us a standard to measure those things against without enumerating every possible violation of the standard. A governance procedure can take context into account, and is much more easily subject to improvement and revision than a contract is.

Sometimes it's the little stuff, more subtle than the booth babe/groping/assault/slur kind of stuff, that makes a community feel inhospitable to me. When I say "little stuff" I am trying to describe the small ways people marginalize each other: dominance displays, cruelty in the guise of honesty, the use of power in inhospitable ways, feeling unvalued, "jokes", clubbiness, watching my every public action for ungenerous interpretation, nitpicking, and bad faith.

Changing these habits requires a change of culture, and that kind of deliberate change in culture requires people who take up the responsibility in stewarding the culture.

And a governance approach has a lot more ability to affect culture than a contracts-only approach does.

2. Contracts give us an illusion of equality and self-containedness

As Tim McGovern said in the comments to my Crooked Timber post:

contracts have taken over as a primary way of negotiating relationships: a EULA is a replacement for a legal understanding of the relationship between two parties who are doing business. I don't, in other words, sign a EULA when I buy a pair of socks -- or even when I buy a car (Teslas excepted) because the purchase relationship is legally defined; even the followup on what can and can't be in your warranty is legally defined. But companies would rather be bound by an agreement they write than a body of law based on either commonlaw or constitutional concepts, or legislation.

Contracts presume an equality between the parties; in theory, both sides can take a breach of contract to court. In practice, of course, a EULA is a contract that masks radical inequality in power between the parties.... Governance requires wrestling with equality in a real way, on the other hand, and voluntarily submitting to an authority constituted in some fashion (over time, by people, etc.), as opposed to preserving a contractual illusion of equality.

3. Contract pretends you have choices

I recommend that, if you haven't, you check out the article "Mothering versus Contract" by Virginia Held, from Beyond Self-Interest in 1990. It suggests that perhaps we should fundamentally conceive of our interactions with others as following a paradigm of motherhood rather than of contract -- one truth this approach acknowledges is that by default most interactions in your life are opt-out rather than opt-in, if there's any opting or choice at all.

Yes, there's the freedom to fork. But realistically, if you want to get things done, you have to collaborate with others, and we need to accede to other people's demands, in terms of interface compatibility, learning and speaking fluent English, and all sorts of other needs. A FLOSS project with a thriving ecology of contributors is far more valuable than a nearly identical chunk of code with only a couple of voices available to help out, and thus the finite amount of human attention limits our ability to make effective forks. We're more inderdependent than independent, and acknowleding that as a fundamental truth complicates the contracts-y libertarian narrative potentially beyond usefulness.

III. Lessons

I hope that my analysis helps give some vocabulary and frameworks for understanding arguments around these issues, and that we can use them to develop more effective arguments.

A. Freedom tradeoff comparisons

The first step might be — if you're trying to get your community to adopt a code of conduct, you might benefit by looking at other freedom-restricting tradeoffs the community is okay with, so you can draw out that comparison.

Or with UX (user experience) -- design is the art of taking things away, and when you're advocating for better user experience, which often involves reducing the number of visible ways to do things, consider comparing your approach to one of the freedom tradeoffs that your interlocutor is already okay with, such as the fact that your community has standardized on a single version control system. A single way for that kind of user to interact.

B. Artifacts

And if you're trying to build a code of conduct consensus in your community, it might help to start by talking, not about day-to-day beavior, but about artifacts that people think of as artifacts. Talk about the things we make, like slide decks for presentations, articles on your wiki. That can get people on the same page as you, in case they're not yet ready to think of the community itself as an artifact we make together.

C. Theory of change

If you're an advocate for a new initiative, licensing, code of conduct, or something else, understand your own theory of change, and build mental models to help you understand the people who disagree with you. Understand what part of the theory of change they disagree with, and gather data to counter it.

And, incidentally, this lens will also help you appreciate other complementary approaches that will help you achieve your goals. As Mike Linksvayer says: "Of course I think that copyleft advocates who really want to ensure people have software freedom rather than just being enamored of a hack should be always on the lookout for cheaper and/or socialized enforcement (as implied above, control of distribution channels that matter, and state regulation)."

So why might people oppose codes of conduct? Here are a few ideas:

As Chris Webber notes, "there's an argument that achieving real world social justice involves a certain amount of process, laying the ground for what's permitted and isn't, and (if you have to, but hopefully you don't) a specified direction for requiring compliance with that correct behavior." The addendum is that, as Alberto Brandolini said "The amount of energy necessary to refute bullshit is an order of magnitude bigger than to produce it." So part of the mental model you're trying to understand is what the person you're arguing with is trying to maximize, and another part is whether you agree on how to maximize it.

Paul Davis, the Ardour BDFL, commented on my Crooked Timber post, "The dilemma for a mid-size project like mine is that the overhead of developing and maintaining a CoC seems like just another thing to do amidst a list of things that is already way too long, and one that addresses a problem that we just don't have (yet)." He said he's more worried about technical, architectural decisions causing developer loss.

So, for instance, you could argue with Paul: what genuinely causes developer loss? And what priorities should you have, given your goals?

D. A fresh set of governance needs and questions

CoC adoption drives the adoption of explicit governance mechanisms, as Christie Koehler has recently explored in depth in her post "The complex reality of adopting a meaningful code of conduct" .... but we have many open questions that the legal and policy community within free and open source could really help with.

For instance, it's great that we have people like Ashe Dryden and organizations like Safety First PDX helping develop standards and advising organizers on developing and enforcing codes of conduct, but should we actually be centralizing this kind of reporting, codification and enforcement across the FLOSS ecosystem? Different subcommunities have different needs and standards, but just as OSI has helped us stave off the worst possibilities of license proliferation, maybe we should be avoiding the utter haphazardness of Code of Conduct proliferation.

And -- given how interconnected our projects are -- what if single open source projects are the wrong size or shape or scope for this particular aspect of stewardship and governance?

I'd very much appreciate thoughts on this from other folks in future devroom talks or blog posts -- if you tell me this is the kind of thing we talk about on the FLOSS Foundations mailing list then maybe I'll have to bite the bullet and go ahead and subscribe.

IV. Other thoughts + Conclusion

A. Comments on my CT piece

The comments on my Crooked Timber piece had many fine insights, on enforcement, culture, exit, voice and loyalty, fairness, and the consent of the governed. They're worth reading.

B. Hospitality to liberty spectrum

In addition to the contract-governance contrast, I think it's also worth thinking about the spectrum of liberty versus hospitality. The free software movement really privileges liberty, way over hospitality. And for many people in our movement, free speech, as John Scalzi put it, is the ability to be a dick in every possible circumstance. Criticize others in any words we like, and do anything that is not legally prohibited.

Hospitality, on the other hand, is thinking more about right speech, just speech, useful speech, and compassion. We only say and do things that help each other. The first responsibility of every citizen is to help each other achieve our goals, and make each other happy.

I think these two views exist on a spectrum, and we are way over to one side, the liberty side, as a community, and moving closer to the middle would help everyone learn better and would help us keep and grow our contributor base, and help make it more diverse. And to the extent that comparing codes of conduct to copyleft licenses helps some people put new initiatives in perspective, balancing the relationship between rights and responsibilities, perhaps that can also help shift our culture into one that's more willing to be hospitable. I hope.

C. This feels like a potentially insoluble problem

William Timberman said in Crooked Timber comments, "how does a socialist persuade a libertarian that coherence and the common good is sometimes a legitimate constraint on individual freedom?" And the answer is that I don't know, but I hope it is a soluble problem, and I hope I've opened up some avenues for exploration on that topic. Thank you.

Filed under:


(3) : Star Wars: The Force Awakens: I saw the original trilogy many years ago and just don't remember a lot of stuff. I was maybe sixteen; I missed my window for really loving it, in keeping with that old saying, "The golden age of science fiction is twelve." And then I saw Phantom Menace -- standing in line for it and all -- with my then boyfriend, when it came out, and then we had our first real argument, because I didn't like it and he did. Past Sumana, bewildered and frustrated in that dorm hallway, you are not wrong, basically the entire critical consensus agrees with you, and someday you will learn to trust your own aesthetic judgment.

In any case: even though I'd never seen Episodes 2 or 3, and I barely remembered the others, The Force Awakens was totally accessible and fun for me. I walked in as someone who thought Boba Fett was one of Jabba the Hutt's names, and I was fine.

I've heard that -- to trufans -- there's sort of a red herring happening in The Force Awakens about someone being set up to be the next Jedi. I did not see it, and I think one reason is that I don't know anything about what the harbingers of Jedi are, but also I think it's because I am such a nonfan that when I am watching a Star Wars movie I do not automatically think "ah there will have to be a new generation of Jedi, so who will it be?" It has not soaked in for me that Star Wars is fantasy and that the way we solve problems is by finding and training people sensitive to the Force. I have Star Trek in my DNA instead (like Leonard) so I assume that the way we solve geopolitical problems is by, like, being transgressively inclusive and making good arguments.

P.S. Does "TFA" mean Star Wars: The Force Awakens or two-factor authentication? In my upcoming fanfic on security in lightsaber summoning, both! Although I may need to figure out whether the Force is something you have, something you are, or something you know.

P.P.S. I will not be writing that fanfic, but you go ahead and feel free. Happy new year!

Edited to add at 11:45pm PT: OK, I wrote the fanfic. "Security Question" is about why a young Jedi apprentice can't shortcut the anti-theft system on the lightsabers by Force-summoning the two-factor auth token itself.

Filed under:


(2) : Thoughtcrime Experiments, One Year Later: Today is the one-year anniversary of Thoughtcrime Experiments, the free scifi/fantasy anthology Leonard and I edited last year.

Thoughtcrime Experiments cover

Thoughtcrime Experiments got a bit of recognition in the form of award nominations. We made the British Fantasy longlist (voting closes 31 May). The Variety SF blog loved Ken Liu's "Single-Bit Error" and considered it one of the best short stories of the year. And Patrick Farley's "Gaia's Strange Seedlike Brood (Homage to Lynn Margulis)" has made the Ursa Major shortlist. We'll find out if he won next month.

Another form of recognition was the sharings, remixings and adaptations we hoped would happen when we released Thoughtcrime Experiments under a Creative Commons license.

LibrisLite, an ebook-reading application, includes our anthology as a free sample book. Marshall T. Vandergrift made a hand-crafted ePub edition, Arachne Jericho made ePub, Kindle/Mobipocket, Microsoft Reader, and Sony Reader editions, and manybooks.net provides the book in many formats. Andrew Willett's short story "Daisy" received a lot of love this way, including an audio recording read by Ian McMillan and an upcoming project I can't mention yet. A fan also read it aloud at a storyreading party.

Mary Anne Mohanraj and Sumana Harihareswara at WisCon in 2009(To the right: E. J. Fischer's photo of me with Mary Anne Mohanraj, author of "Jump Space.")

We were also gratified to see people thinking about, reviewing, enjoying, and linking to individual stories and illustrations.

"Jump Space" by Mary Anne Mohanraj got substantial thoughtful attention, such as Rachel Chalmers's review:

"Even cooler, the story they sort of chose for me is "Jump Space", which I purely love. It's a head-on collision between the Heinlein juvenile adventure stories I adored as a kid - the Have Spacesuit Will Travel or Space Family Stones - and a thoroughly 21st century set of attitudes towards love, sex, dating one's professor, marriage, faithfulness, jealousy, prostitution, slavery and even raising children (my main preoccupation these days and one that Heinlein tended to rather idealize...)

Erica Naone's review of "Jump Space", in part:

I think the anthology is trying to explore a wider variety of human elements and viewpoints than are seen in the typical science fiction anthology...

Mary Anne Mohanraj's "Jump Space" has some of the most fully realized relationships that I've seen in science fiction.... the theme of love's simultaneous strength and fragility was emphasized against the backdrop of space. Love and family seem even more accidental and precarious when the universe is so large.

Mohanraj wrote a post about what she did wrong & right in "Jump Space". Hugo Schwyzer posted about "Jump Space" and academic ethics (specifically, on initiating professor-student romance), to which Mohanraj replied.

Rachel Chalmers's review continued:

I liked "Jump Space" so much that I was startled to find a story in Thoughtcrime that I liked even better. It is "Single Bit Error" by Ken Liu. Can't tell you much about it without spoiling a rather excellent surprise, but wow, it's just a stunner. Weaves together theoretical computer science and existential philosophy in a way I've always thought could be done, but never quite managed to do or see anyone else doing...

You should allow for my extreme bias in favor of my friends; despite this utter lack of objectivity I recommend this anthology to anyone who's interested in the best and bravest modern science fiction.

Bio Break by Brittany Hague(To the left: "Bio Break" by Brittany Hague.)

Kit Brown wrote: "I really liked Daisy by Andrew Willett and Single Bit Error by Ken Liu. I also loved Robot vs Ninjas by Marc Scheff and snagged it to add to my desktop wallpaper rotation."

Erin Ptah's illustration "Pirate vs. Alien" also got some attention: "More silliness may be found in this picture by Erin Ptah, wherein a buxom pirate battles a well-endowed alien who appears to be preparing to give himself a shave."

Lynda Williams says of "The Ambassador's Staff," a short story by Sherry D. Ramsey: "Well put together, goes down smooth, and captures my feelings about too little sleep and too much coffee, to boot. Allegorically speaking."

Sam Tomaino calls Thoughtcrime Experiments "an anthology filled with stories that I enjoyed thoroughly". And Jane Irwin of Vogelein liked it, especially "Daisy".

Erica Naone's thoughtful reviews of several Thoughtcrime Experiments stories are another useful resource; I can't quote them all here or they'd take up half the post!

One manybooks.net reviewer says:

When I saw the "mind-breakingly" description, I thought to myself, "No way, that is just too ambitious." Well after reading the first five or six stories, I must say I agree. This seems to be another example of really good authors publishing under the Creative Commons. Welcome to the future.

Other readers posted about the Creative Commons and DIY facets of our project interesting:

rollicking....The anthology wears its DIY cred on its sleeve and even has a how-to appendix and all the source code for the website is gank-able. It’s available as a free download or POD book. Keep Circulating the Tapes!...

They're publishing because they want to give back to the community. They have no illusions about reaping financial gains from these transactions, and that's okay. We all do things for love that we would never do for money....

The point of Thoughtcrime Experiments is its punk/hacker ethic. You don't have to wait for Gardner Dozois or any of the other 'masters of the genre' to make an anthology for you, you can go out there and do it yourself. If you can't find a magazine publishing SF you'd like to read, and feel they're all publishing the same tired stuff, Much like their punk predecessors at 'Sideburns' they have an appendix on "How we did this". It's the three-chord diagram for a revolution in SF.

Now, it probably won't catch on. Just because punk happened, doesn't mean one can start a revolution every time one is needed. But imagine if it did. Imagine if the kids started getting together, and producing their own SF magazines. Imagine if SF became, for some small portion of the population, the new rock-and-roll, or at least the new indie-rock....

But it's not just the anthology that's interesting. Leonard used this entire project to better understand the editing process. His conclusions are quite interesting for writers. Basically, that we don't suck as bad as we think we do just because we get so many damn rejections...

Times Square by David Kelmer(To the right: "Times Square" by David Kelmer.)

Another author talked about our anthology while considering commodification, scarcity, and publishing. And Freedom to Tinker noted,

Still, part of the new theory of open-source peer-production asks questions like, "What motivates people to produce technical or artistic works? What mechanisms do they use to organize this work? What is the quality of the work produced, and how does it contribute to society? What are the legal frameworks that will encourage such work?" This anthology and its appendix provide an interesting datapoint for the theorists. (See Leonard's response.)

Jed's repost of our call for submissions, and his announcement once we were out, also commented on the ripples our project might send out: "So I'm hoping, as Leonard and Sumana are hoping, that in addition to providing a good read, this anthology will inspire others to embark on new publishing ventures."

If you want our thinky thoughts about the whole venture, you might be interested in Sharon Panelo's interview with me, my length anthology retrospective and thoughts on scifi publishing, more such, and Leonard's many interesting posts on the stories, the process, and what we learned about the field. And I hope we get that Hour of the Wolf radio show interview up for download/reading sometime soon.

To finish up the link roundup: Grasping in the Wind, BoingBoing, Tor.com, John Scalzi, Baby Got Books, and Locus also notified their readers of our existence, for which we are grateful.

The book's still up. Read or download it for free, or buy a paperback for USD5.09 plus shipping. I'm arranging to have about seventy copies for sale at cost at WisCon.

If I missed your review, please post a link in the comments!

Filed under:


: Let's Hear It For (Labors Of) Love: Here is another narrative of my WisCon: something I learned from editing and publicizing Thoughtcrime Experiments, and what that makes me want to do next. It's long (the longer the post, the more I feel I'm leaving out), but there's some filk silliness at the end. (Title hat-tip to the Smokin' Popes; cue up Destination Failure while reading this, it'll take about that long.)


I arrived with ten copies of Thoughtcrime Experiments and nearly immediately gave away or sold them. I probably could have sold fifty, if I'd had them. I made about 200 copies of my flyer (seven-megabyte PDF, used a canned iWork Pages template) and people eagerly took them. I got to show contributor Alex Wilson Erica Naone's reviews of the stories, including her review of his "The Last Christmas of Mrs. Claus." In the "Was It Good For You?" panel, I mentioned three stories that made me feel unusually at-home: Connie Willis's "Even the Queen," my fellow panelist K. Tempest Bradford's "Élan Vital," and Mary Anne Mohanraj's "Jump Space" from the anthology I just published, squee!

Throughout the convention, people sounded receptive when I chattered about the anthology. Several people told me how exciting they found our project, and a few made noises about following Leonard's instructions and conducting the experiment themselves. And a few people said: "what are you doing next?" or "when you do it again next year..." A flattering boost and a natural assumption, but not a completely justified one.

Do I want to do it again? Good question!

In the "Was It Good For You?" panel, I observed that some editors and authors start with a vision they need to express (my nickel version of auteur theory), and some start wanting to respond to a community's need for certain viewpoints or stories. The way Leonard and I divided up anthology work reflects that division. He did line edits, pushed for more variety in the art, exhausted himself tweaking the layout to perfection, indeed conceived the project in the first place. I publicized the call for submissions, recruited artists, read slush and wrote rejections, and promoted the finished book electronically and in person.* My revealed preferences: sociable work. I want my work to make others happy. (When we got the first galley proofs from CreateSpace, I said it's real. But the reality of the literary marketplace is socially constructed, and foisting Thoughtcrime publicity onto hundreds of minds at WisCon transmuted the book into something more real.)

But how many people experienced any happiness from Thoughtcrime Experiments? A few thousand downloads and page hits, maybe ten thousand fleeting "oh it's neat that they did that" impressions. Is that enough? Would I spend my energy on a sequel anthology for a readership of less than, say, fifty thousand?

I mean, when I promoted the call for submissions, and when I went to WisCon, I couldn't help but see how many quality small presses and mags our genre enjoys. Shimmer, Goblin Fruit, GUD, Ideomancer, Small Beer, Electric Velocipede, Clarkesworld, Andromeda Spaceways Inflight Magazine**, Strange Horizons***, Verb Noire, Aqueduct... I'm just going off the top of my head. Some are electronic, some are print, some are more regular than others, but it's not like any one part of Thoughtcrime is new. Rejected Quarterly plus Creative Commons licensing (already done by Stross/Doctorow, not to mention Strange Horizons & others) plus easy online reading (several abovenamed pubs) plus good payrates (several again) plus gumption (passim). Thoughtcrime is a tiny fish in the pond.

When I see us in context, of course we've gotten maybe 4 emails of praise and 10 blog mentions from people who don't know us. What kills me is how little attention all these presses get. If Leonard weren't an author seeking markets, he wouldn't have started Thoughtcrime, and I wouldn't have heard of most of these presses and magazines. I'd see Tor's and Orbit's stuff in the bookstores, and maybe if BoingBoing or Tor.com or Making Light**** said something really positive about a particular story online I'd go click.

The ease of publishing doesn't mean readers automatically get hooked up with content they'd enjoy. Publishing is a binary switch, off to on, and new technology makes it cheaper to pull that switch. But publicizing -- marketing -- is analog, and really lossy. I'll only persuade a percentage of my desired audience to go read x, and I'll only ever hear about the fraction of that percentage that somehow signals back. Logs and analytics just tell me about impressions, not lasting impressions.

I am like the googolith person to observe, "it's a shame awesome indie stuff doesn't get as much mindshare as the mainstream does! It is almost as if having a large, established, for-profit publishing apparatus is good at turning capital into reputation, accessibility, and distribution!"

But just as I should be less in love with originality when appraising my past work (so what if Thoughtcrime did no one new thing? It combined a bunch of those things for the first time and it's a damn fun read), I don't have to put auteur-y novelty first on my priority list when allocating my future efforts. Why should I just turn five or nine stories from 0 to 1 on the publishing meter when I could get thousands of great stories from 1 to 2 or 5 or beyond?

Well, that "beyond" would be pretty tough. One assessment that sounds oppressively real: "The problem for SF writers and publishers today isn't that there's not a mass audience for high-end SF storytelling; it's that there are immense numbers of other diversions on offer for those hundreds of millions of people." Why should a person read at all, and if she reads why should she read the particular work I adore and want her to read? What particular need would I be uniquely fulfilling in her? Because that's where marketing starts: identifying or arousing a need.

I can reckon how a person might go about increasing the mindshare of any given indie scifi publisher among people who already consider themselves scifi fans. It's never been a better time to be a publisher or a cheapass reader; Amazon, Bookmooch, ManyBooks, Goodreads, DailyLit, the Kindle, blogs like Tor.com and BoingBoing, and other resources help hook up readers with the abundance of awesome fiction that already exists, for free, online. (If you are a cheapass scifi reader and you are saying, "Where do I start? SHOW ME THE FREE STORIES," Futurismic's Friday Free Fiction weekly roundup will get you started.)

Indie publishers still need a little marketing to get into many of those channels. Search engine optimization, some tech hairdressing, and time writing the equivalent of press releases come to mind. I can see a path to getting a rabid scifi fan to taste something new. I'd grow the market a little (rewarding!), but also displace the readership of my rivals, Big Publishers and other small presses (kind of disheartening!). I actually don't know how zero-sum the economics of this project would be, and am curious; I'd want to collect a lot of metrics, and set a quantitative goal in hopes of avoiding existential despair.

But the project of turning nonreaders into occasional sci-fi readers, and occasional readers into rabid readers? Unsolved and incredibly exciting. I'm wondering who else is doing this, and how; comments welcome.

I would like to make the pie higher, as the saying goes. Thoughtcrime Experiments will never be a huge slice of it in any case, and I'm not so delusional as to think it's objectively the tastiest portion.

So Leonard and I have different ideas for what's next (not that either of us is about to start anything; our jobs, writing, travel, friends, worries, etc. are consuming us for now). He's tentatively interested in doing what Brendan dares us to call Again, Thoughtcrime Experiments. I'd help again if he wanted. We found stories we loved and made them more real, and I love doing that. But my ambitions point me in another direction: scaling up.


* It wasn't till like three months into Thoughtcrime that I realized I was following in my parents' footsteps. My parents did a zine! Amerikannada, the literary magazine my parents ran for several years, printed fiction and nonfiction by the Kannada-speaking diaspora in the United States. The Amerikannada logo was a hybrid eagle-lion. They've been editing and writing and celebrating Kannada literature for decades, but I remember Amerikannada specifically because I got to help with kid-friendly mailing chores. After Leonard and I had an argument about art direction, I felt like I'd unlocked a memory of another editorial argument, conducted over my head as I pasted stickers to envelopes in the rec room of the first California house. I have no idea whether that's memory or invention, and indeed know nothing of how Mom and Dad divvied up the work, ran submissions, decided on timetables, or made any of those editing/publishing decisions I now find fascinating. I should ask them.

** You can sing "Andromeda Spaceways" to the same meter as "American Woman." As long as you're here: "Goblin Fruit" works as "Stacey's Mom" ("Goblin Fruit / is made of hemp and jute") and I always want to sing "Clarkesworld" to the tune of "McWorld!" from those old McDonald's ads.

*** Strange Horizons is a special case all on its own. When I started realizing that they've been publishing quality fiction and nonfiction weekly for more than seven years, paying pro rates, and generally been ahead of every curve I thought I was exploring, I couldn't believe that I hadn't been a fangirl earlier. I'm feasting on archives now, especially their reviews. You can start with Anathem and Little Brother, and then see if you find this analysis of Ted Chiang's work and this West Wing analysis as thought-provoking as I do.

**** I have been reading the Nielsen Haydens for like six years or more. Patrick and Teresa taught Leonard at Viable Paradise, and Patrick gave Leonard advice before we launched the anthology. We thanked them in the acknowledgments to Thoughtcrime. Teresa reminds me of my late mother-in-law, Frances, in a lot of ways. And yet, and yet.***** Nora speaks better than I could.

***** I meant to write about WisCon racism discussions weeks ago. Explanation seems impossible, so I'll sum up. Thank you, Rachel Chalmers, for putting my head straight when I saw you in January. Thanks to all the antiracists who have put spoons into this discussion, in education and anger both. And thanks to WisCon 33 and its participants, for being the place where I had drinks and panels and meals with uncountable fans of color. (Pleasantly disorienting: the meal where I was the only heterosexual and the only monogamist but not the only woman or person of color.)

My perspective on race in fiction has shifted. The short edition: if you write or edit or critique fiction, looking out for lazy racism is no longer optional. Analogies: 1. The feminist infrastructure is strong enough that sexist writing gets a bunch of flack, and the antiracist infrastructure is getting there. 2. An antiracist lens is going to be a usual mode of critique from now on. This is part of the new normal. The discourse has shifted. Someone trying to pretend this is a fad or a personal attack is like the RIAA lashing out to protect business models that no longer work. Some thoughts on problems and solutions in an upcoming post, I hope.

Filed under:


(1) : Thoughtcrime Experiments Anthology Is Up: Nine new original stories, five new original artworks, and an essay on how and why we did it. Read it online, download the PDF, or (soon) buy the print-on-demand book. Link, download, read, and remix away -- it's all Creative Commons-licensed.

There isn't a theme, really, just "what we like." It turns out that we like political satire and family drama and detective thrillers and fables and fable deconstructions and the mysteries of debugging. It's all good stuff and we hope you like it.

Filed under:



[Main]

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at sumanah@panix.com.