<M <Y
Y> M>

(1) : No Minimum Order: The office/business supply company Uline has discovered that I have started a business, and thus I have started to receive giant catalogs from them. Yesterday Leonard and I started looking at those catalogs; perhaps you saw my tweet about crinkle paper:

the https://t.co/iJpdxCpQQX catalog reminds me: some possessions, work are "attractive void fill" pic.twitter.com/hgCfUxq9oR

— Sumana Harihareswara (@brainwane) March 6, 2016

As I kept reading, I was struck by how this catalog systematically lists the unnoticed objects that surround me in every office, workplace, shop, hotel, restaurant, and school. Certainly I had marveled, as a child, going into the Office Depot with my dad and seeing the boxes of badge holders, the desks and chairs, the day-to-day accoutrements of bureaucracy. But the Uline catalog goes further. Uline sells desiccant packets and takeout boxes and those gridded walls to hang merchandise from and bollards and red velvet ropes and PLEASE WAIT HERE signs and mats for cashiers to stand on and benches and wheeled utility carts and feminine hygiene dispensers.

I feel a curious awakening, as though given X-ray glasses for one of the systems that make the world go. I knew you could get these sorts of things on Amazon, sure, but I had not yet been confronted with a curated list. I don't have any plans, right now, to open a storefront or run a warehouse, but this list of products helps me see how I could. I would buy these things, and they would organize and streamline my operations, and my customers and my workers would react accordingly. I could put up a STOP sign, and people would stop. I could place a clothes rack near the entry to an event, and people would leave their coats there. I could put my team in white coveralls, and they would distinguish their colleagues from outsiders. The Uline catalog promises ways to make your world safer, cleaner, calmer.

But, reflexively, I also see this catalog as a set of heists, scams, and cons waiting to happen. You can buy and customize tamper-evident shrink bands for the caps of bottles -- and thus hide evidence of your own tampering! What better way to get a saliva sample from a smoker than by installing your own smoker's receptacle someplace you know they'll be? Reserve more handicapped-accessible parking spaces wherever you want by buying and installing "reserved parking" signs!

I am an entrepreneur and a manager who dreams about building things and works to build some subset of those things. And I am a suspicious security thinker who imagines ways to break and steal things, and blows off steam by talking about movie plot threats with her spouse, who transmutes a fraction of those conversations into science fiction. And on some level I am void fill, as are we all.

Filed under:

: Endorsements, Sort Of: This week, when searching for my own name online, I came across these three judgments of my works and character:

  1. About my January talk "Comparing Codes of Conduct to Copyleft Licenses", which I delivered without visual accompaniment: "Sumana gave a very well argued speech without media support, leaving clues of a probable theatrical past (or present)." Indeed I suspect my stand-up comedy practice helps me deliver good presentations, as does my experience teaching, and that both those skillsets serve me well when I choose to go slidesless.
  2. In response to a Salon article I wrote in 2003, a contemporaneous reader listed me as #1 in a list of "People who smoke crack". (I do not.)
  3. Discussing a WisCon panel I spoke on a while back, an anonymous and often scurrilous message board includes this chunk of conversation, neither as laudatory as #1 nor as scornful as #2 in this list:

    That list of panelists is like a who's who in horrible people and their enablers.
    Does Sumana have a wanky reputation? I didn't know that.
    I was thinking of everyone other than her, her I don't know that well.

    I find it hilarious that the anonymous poster is not, at this time, smearing me, but that I should not count on their permanent forebearance in this matter.

As the skeptical idiom goes, take it with a grain of salt -- in some cases a grain so large it may serve as a lick for deer.

Filed under:

(1) : N Questions: Leonard and I have taken to playing a kind of "Twenty Questions" variant where there is no limit on the number of questions or guesses. We discover stuff about ourselves along the way. Sometimes it turns out the guesser has not heard of the item in question (e.g., Rick Bayless) or the teller doesn't know as much as they thought they did about the item they chose (e.g., the Bilderberg Group). Also I often ask whether we have the thing and whether we like it; Leonard is less likely to ask those kinds of personal relationship questions. Tonight's items included several abstract concepts or categories of objects and some super-specific concrete nouns:

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:

: Two Conferences, Three Talks: Last week I took the train to Atlanta to speak at the Great Wide Open conference, which I'd never visited before. I particularly appreciated the chance to share my lessons learned with an audience that was diverse on gender, ethnic, speciality, and other dimensions, the cozy and delightful speakers' dinner, and the organizing team's consistent approachability and helpfulness. If Atlanta is an easy trip for you, and if you're interested in growing your skills in free and open source software, I suggest you consider attending next year.

I spoke on underappreciated features in HTTP, and my slides are available as a PDF. If you're going to be at PyCon North America in Portland, Oregon this year, I'll be presenting a more Python-specific version of this talk there on May 31st. If neither of those works for you, check out the video of the very similar "HTTP Can Do That?!" presentation I delivered at Open Source Bridge last year.

Then I rode the train north to Boston; along the way I got to converse with a neat seatmate, a military veteran who loves taking family walks after dinner to play Ingress with his kids. Awww. His son loves Minecraft so I got to recommend the NYPL historical-map Minecraft worlds to him.

Then, this past weekend, I attended my first LibrePlanet. What a lovely time I had! I saw rockin' talks by people whose thoughts I was already eager to hear, and I met dozens of people who are working on promising projects like a nonprofit, transparent search for the web and a browser extension that lets users share their internet connections with people whose connections are censored. I especially commend the organizers for running the conference, including the video streaming, using entirely free and open source software! Since we knew that all of us are dedicated to software freedom as a goal in itself and towards a more just and a freer world, we could have complex conversations that advanced beyond first-contact advocacy and into details and long-term planning.

I spoke on "Inessential Weirdnesses in Free Software"; the written remarks I spoke from are now available as a text file. It is not the most legible page in the world, because I will be further revising this talk before presenting it at OSCON in Austin, Texas, on May 18th.

I also delivered a somewhat impromptu five-minute lightning talk, "What is maintainership? Or, approaches to filling management skill gaps in free software". I've now posted the textual version of that talk.

LibrePlanet participants told me they really liked both my talks; the latter especially spurred some to talk with me about potential contracts with my firm, Changeset Consulting, which was a big morale injection since I'm definitely seeking leads and referrals right now.

Thanks to both LibrePlanet and Great Wide Open for having me speak! I've also updated my Talks webpage with links to my upcoming appearances. My calendar's open after August, in case you know anyone looking for a speaker who makes a lot of jokes and gestures.

Filed under:

: Tips To Increase Your Conference Talk Acceptance Rate: This year I submitted talks to several tech conferences and got a higher acceptance rate than I had been used to. For instance, this year I will speak for the first time at OSCON and PyCon North America, conferences that had previously rejected my proposals.

Why did this happen? I am a more polished and experienced speaker than I was in previous years, yes; program committees can see more videos and read more transcripts of my past talks. I have a better résumé and more personal connections. And through practice, I've gotten past the "get ideas on the page" stage of writing conference proposals, and learned how to better suggest a useful talk relevant to the audience.

Those factors you can't replicate today. But some, you can. Here they are. I believe following these tips will increase the acceptance rate for your software conference talk submissions.

Learn what they need.

Check whether you already know someone involved in selecting talks for the conference or a sub-track. If you do, ask them if they have any topic gaps you could help fill. Maybe they've gotten no talks yet on, say, Python web frameworks other than Django; they might specifically encourage you. And even if you don't know the con-runners personally, check their social media presences, in case they've spoken there and specifically asked for more talks about certain topics, or more talks from people from underrepresented perspectives or groups (example).

If this conference has happened before, look at the previous year's schedule; look for the range of the possible. What is this conference's universe of discourse? This helps you match the audience's interests and helps you avoid duplicating a conference talk from last year. What topics are adjacent to the topics they already seem to have covered?

Speaking of duplication, here's my take on "repeating yourself":

Tell them if you gave the talk already.

If you've given the talk before, say so, and link to the text, transcript and video/audio. Having all this info ready in your comprehensive "past talks" page is handy (see below). They can try before they buy! If you gave the talk to a standing-room only crowd and great acclaim, say so! And even if that was not the case, if you've already given this talk at another conference, now they know that it was good enough for someone else already, which is a useful social signal. I delivered "HTTP Can Do That?!" at Open Source Bridge last year, and in 2016 PyCon North America and Great Wide Open accepted my proposal to give nearly the same talk.

Different people and subcommunities follow different norms or rules of etiquette in distinguishing rude repetitiveness from sensible re-use. You might be able to lead the same multi-hour skill-building workshop at one convention multiple years in a row. I don't think I'll be re-proposing "HTTP Can Do That?!" in 2017 at any conferences; a 2-year exposure window feels all right to me.

More on reuse:

Reuse your blog post that went viral.

Basing the talk on a blog post or article of yours that got a lot of responses is great. Point to it and to the long comment threads, response blog posts, etc. This demonstrates that the community is interested in your thoughts on this topic, and that you've already thought about it a lot. I have successfully done this by turning my "Inessential Weirdnesses in Open Source" blog post from 2014 into a talk LibrePlanet and OSCON accepted this year.

I know, I said I'd only give you advice you can replicate today. I have no secrets to share about the internet fame lottery. But you can think aloud in a blog post or a Model View Culture essay or LWN article, and get feedback that helps you sharpen your message. Or, if you found someone else's article super provocative, you can ask them to pair up with you and co-submit.

And in general:

Save what you write.

Look at the talk submission form and figure out what they'll want, but write your submission and save it somewhere else. This makes it easier to reuse your proposal for multiple conferences, and to have multiple proposals to submit to any one conference.


Submit two or three proposals to each conference.

If I want to speak at a conference, I usually submit multiple proposals on different topics. I have never heard of a conference that limits speakers to one submission per speaker. The first time it occurred to me to do this: 2009, when I saw that the Open Source Bridge submission system lets everyone see everyone else's submission. I saw that some men were submitting three, four, even five proposals. Oh, you can do that! I submitted three talks, and one got in.

For each of those proposals:

Specify the audience and the takeaways.

Some conference submission forms explicitly ask who the audience is for your talk, or what prerequisites you think they should have. Also, some ask for the objectives of your talk, or what the audience will take away. This is a great question. Give specific answers. Even if the conference doesn't ask for these things, I suggest you include them anyway -- put them in the abstract, additional info field, detailed description, or similar.

Two examples, from talks I successfully submitted. Example 1:

Audience: Developers with at least enough web development experience that they've used GET and POST, but who are unfamiliar with using DELETE or conditional GET

Objectives: Attendees will learn about HTTP 1.1 verbs, headers, response codes, and capabilities they did not know of before, with use cases, example code, and jokes. They will walk away feeling more capable of using more of the HTTP featureset and with a greater understanding of the underlying design of the protocol.

Example 2:

Takeaway: Open source contributors and leaders who are already comfortable with our norms and jargon will learn how to see their own phrasings and tools as outsiders do, and to make more hospitable experiences during their outreach efforts.

Prereqs: Attendees need to already be able to use core open source tools (like version control, IRC, mailing lists, bug trackers, and wikis), and be familiar with general open source culture and trends such as "+1", scorn towards Microsoft Windows, and the argument between copyleft and permissive licenses.

And in each proposal:

Provide a detailed outline.

Be concise in the short-form description, and then write out a big outline for the "more details" or longer abstract. For 45-minute talks I've provided detailed outlines/abstracts of 300-1200 words. The committee can easily infer that you have already thought a lot about this topic and are pretty prepped, and this that there's less risk of you giving a half-baked or rambling talk.

Finally, three more logistical tips:

Get the proposals in on time.

You know yourself. You have probably figured out how to avoid missing appointments and deadlines. Do that. Set up phone alarms, calendar reminders, a boomerang'd email, a Twitter feed subscription, a promise to an accountability buddy, what have you.

Publish a "My past talks" page.

Here's mine. List your past talks, including workshops and classes you've led and podcasts or interviews that feature you. Where possible, link to or embed sample video and audio so a conference can try before they buy. If you can, name the conference, place, and year for each one; in some cases it might make more sense to say "led weekly brownbag talk series, Name of Employer, 2010-2012" or similar. A longer public speaking résumé means you're less of a risk.

Customize your bio.

A good biographical paragraph establishes your credibility and likelihood to speak about the subject and say interesting things. For instance, I've taught interactive workshops before, and I've won an Open Source Citizen Award. Sometimes I put this kind of thing in my bio, sometimes in an "additional info" field. This is one place that a comprehensive "My past talks" page comes in handy. I can cut and paste stuff from that page into a customized bio that demonstrates why I'm a great choice to give this talk.

That's what I know so far.

I add my voice here to the multitude of resources on this topic, and especially commend to you Lena Reinhard's excellent and comprehensive talk prep guide and the weekly Technically Speaking email newsletter.

Thanks to Christie Koehler for the conversation that sparked this post!

Filed under:


You can hire me through Changeset Consulting.

Creative Commons License
This work by Sumana Harihareswara 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 sh@changeset.nyc.