Cogito, Ergo Sumana

Categories: sumana | Work

(2) : Alternate Questions: Is it still in vogue for US tech companies to ask quantitative estimation/implausible-problem questions like "how many phone booths/piano tuners are there in Manhattan?" in hiring interviews, particularly for programming-related jobs? Fog Creek asked me one of those in 2005. There was even a book, How Would You Move Mount Fuji?: Microsoft's Cult of the Puzzle -- How the World's Smartest Companies Select the Most Creative Thinkers.* How many companies are still into that?**

I ask because I came up with a couple you could use, maybe for a digital humanities kind of position:

  1. How many people, throughout history, have actually been named "Flee-From-Sin"? I feel like you see this as a jokey Puritan first name in books like Good Omens or the Baroque Cycle, but was it a name that some non-negligible number of people actually had?
  2. Out of all the people currently within New York City limits, have more of them written a sonnet or a dating profile? What's the ratio?

* That's right, two subtitles. That's how you know you're getting a lot for your $16.00 MSRP.

** It's hard to tell these things sometimes even if you listen to lots of people discuss hiring and recruiting. "Five Worlds" and its decade-later ramifications apply to work culture, not just software development methodology. Stripe's engineering interview aims to "simulate the engineering work you'd do day-to-day" (link via Julia Evans) so I think you can expect your interviewer won't show up wearing a question-mark costume and screeching, "Riddle me this, Batman!" This software engineer, who's just been through scads of hiring interviews, doesn't mention puzzle questions. This level of detail ain't exactly on the "How to Become a Computer Programmer" page in the Occupational Outlook Handbook from the US Department of Labor -- but then again we already knew that the assessment vacuum in software engineering skills is a huge problem.

Filed under:

(1) : Inclusive-Or: Hospitality in Bug Tracking:

Lindsey Kuper asked:

I’m interested in hearing about [open source software] projects that have successfully adopted an "only insiders use the issue tracker" approach. For instance, a project might have a mailing list where users discuss bugs in an unstructured way, and project insiders distill those discussions into bug reports to be entered into the issue tracker. Where does this approach succeed, and where does it fail? How can projects that operate this way effectively communicate their expectations to non-insider users, especially those users who might be more accustomed to using issue trackers directly?
More recently, Jillian C. York wrote:

...sick of "just file a bug with us through github!" You realize that's offputting to your average users, right?

If you want actual, average users to submit bugs, you know what you have to do: You have to use email. Sorry, but it's true.

Oh, and that goes especially for high-risk users. Give them easy ways to talk to you. You know who you are, devs.

Both Kuper and York get at: How do we open source maintainers get the bug reports we need, in a way that works for us and for our users?

My short answer is that open source projects should have centralized bug trackers that are as easy as possible to work in as an expert user, and that they should find automated ways to accept bug reports from less structured and less expert sources. I'll discuss some examples and then some general principles.

Dreamwidth logo Dreamwidth: Dreamwidth takes support questions via a customer support interface. The volunteers and paid staff answering those questions sometimes find that a support request reveals a bug, and then file it in GitHub on the customer's behalf, then tell her when it's fixed. (Each support request has a private section that only Support can see, which makes it easier to track the connection between Support requests and GitHub issues, and Support regulars tend to have enough ambient awareness of both Support and GitHub traffic to speak up when relevant issues crop up or get closed.) Dreamwidth users and developers who are comfortable using the GitHub issue tracker are welcomed if they want to file bugs there directly instead.

Dreamwidth also has a non-GitHub interface for feature suggestions: the suggestions form is the preferred interface for people to suggest new features for Dreamwidth. Users post their suggestions into a queue and a maintainer chooses whether to turn that suggestion into a post for open discussion in the dw-suggestions community, or whether to bounce it straight into GitHub (e.g., for an uncontroversial request to whitelist a new site for media embedding or add a new site for easy cross-site user linking, or at the maintainer's prerogative). Once a maintainer has turned a suggestion into a post, other users use an interface familiar to them (Dreamwidth itself) to discuss whether they want the feature. Then, if they and the maintainer come to consensus and approve it, the maintainer adds a ticket for it to GitHub. That moderation step has been a bottleneck in the past, and the process of moving a suggestion into GitHub also hasn't yet been automated.

Since discussion about site changes needs to include users who aren't developers, Dreamwidth maintainers prefer that people use the suggestions form; experienced developers sometimes start conversations in GitHub, but the norm (at least the official norm) is to use dw-suggestions; I think the occasional GitHub comment suffices for redirecting these discussions.

Zulip logo Zulip: We use GitHub issues. The Zulip installations hosted by Kandra Labs (the for-profit company that stewards the open source project) also have a "Send feedback" button in one of the upper corners of the Zulip web user interface. Clicking this opens a private message conversation with, which users used more heavily when the product was younger. (We also used to have a nice setup where we could actually send you replies in-Zulip, and may bring that back in the future.)

I often see Tim Abbott and other maintainers noticing problems that new users/customers are having and, while helping them (via the zulip-devel mailing list, via the Zuliping-about-Zulip chat at, or in person), opening GitHub issues about the issue, as the next step towards a long-term fix. But -- as with the Dreamwidth example -- it is also fine for people who are used to filing bug reports or feature requests directly to go ahead and file them in GitHub. And if Tim et alia know that the person they're helping has that skill and probably has the time to write up a quick issue, then the maintainers will likely say, "hey would you mind filing that in GitHub?"

We sometimes hold live office hours at At yesterday's office hour, Tim set up a discussion topic named "warts" and said,

I think another good topic is to just have folks list the things that feel like they're some of our uglier/messier parts of the UI that should be getting attention. We can use this topic to collect them :).

Several people spoke up about little irritations, and we ended up filing and fixing multiple issues. One of Zulip's lead developers, Steve Howell, reflected: "As many bug reports as we get normally, asking for 'warts' seems to empower customers to report stuff that might not be considered bugs, or just empower them to speak up more." I'd also point out that some people feel more comfortable responding to an invitation in a synchronous conversation than initiating an asynchronous one -- plus, there's the power of personal invitation to consider.

As user uptake goes up, I hope we'll also have more of a presence on Twitter, IRC, and Stack Overflow in order to engage people who are asking questions there and help them there, and get proto-bug reports from those platforms to transform into GitHub issues. We already use our Twitter integration to help -- if someone mentions Zulip in a public Tweet, a bot tells us about it in our developers' livechat, so we can log into our Twitter account and reply to them.

MediaWiki logo 1MediaWiki and Wikimedia: Wikipedia editors and other contributors have a lot of places they communicate about the sites themselves, such as the technical-issues subforum of English Wikipedia's "Village Pump", and similar community-conversation pages within other Wikipedias, Wikivoyages, etc. Under my leadership, the team within Wikimedia Foundation's engineering department that liaised with the larger Wikimedia community grew more systematic about working with those Wikimedia spaces where users were saying things that were proto-bug reports. We got more systematic about listening for those complaints, filing them as bugs in the public bug tracker, and keeping in touch with those reporters as bugs progressed -- and building a kind of ambassador community to further that kind of information dissemination. (I don't know how well that worked out; I think we built a better social infrastructure for people who were already doing that kind of volunteer work ad hoc, but I don't know whether we succeeded in recruiting more people to do it, and I haven't kept a close eye on how that's gone in the years since I left.)

We also worked to make it easy for people to report bugs into the main bug tracker. The Bugzilla installation we had for most of the time that I was at Wikimedia had two bug reporting forms: a "simple" submission form that we pointed most people to, with far fewer fields, and an "advanced" form that Wikimedia-experienced developers used. They've moved to Phabricator now, and I don't know whether they've replicated that kind of two-lane approach.

A closed-source example: FogBugz. When I was at Fog Creek Software doing sales and customer support, we used FogBugz as our internal bug tracker (to manage TODOs for our products,* and as our customer relationship manager). Emails into the relevant email addresses landed in FogBugz, so it was easy for me to reply directly to help requests that I could fix myself, and easy for me to note "this customer support request demonstrates a bug we need to fix" and turn it into a bug report, or open a related issue for that bug report. If I recall correctly, I could even set the visibility of the issue so the customer could see it and its progress (unusual, since almost all our issue-tracking was private and visible only within the company).

Debian logo An interface example: Debian. Debian lets you report bugs via email and via the command-line reportbug program. As the "how to use BTS" guide says,

some spam messages managed to send mails to -done addresses. Those are usually easily caught, and given that everything can get reverted easily it's not that troublesome. The package maintainers usually notice those and react to them, as do the BTS admins regularly.

The BTS admins also have the possibility to block some senders from working on the bug tracking system in case they deliberately do malicious things.

But being open and inviting everyone to work on bugs totally outweighs the troubles that sometimes pop up because of misuse of the control bot.

And that leads us to:

General guidelines: Dreamwidth, Zulip, MediaWiki, and Debian don't discourage people from filing bug reports in the official central bug tracker. Even someone quite new to a particular codebase/project can file a very helpful and clear bug report, after all, as long as they know the general skill of filing a good bug report. Rather, I think the philosophy is what you might find in hospitable activism in general: meet people where they are, and provide a means for them to conveniently start the conversation in a time, place, and manner that's more comfortable for them. For a lot of people, that means email, or the product itself.

Failure modes can include:

Whether or not you choose to increase the number of interfaces you enable for bug reporting, it's worth improving the user experience for people reporting bugs into your main bug tracker. Tedious, lots-of-fields issue tracker templates and UIs decrease throughput, even for skilled bug reporters who simply aren't used to the particular codebase/project they're currently trying to file an issue about. So we should make that easier. You can provide an easy web form, as Wikimedia did via the simplified Bugzilla form, or an email or in-application route, as Debian does.

And FLOSS projects oughta do what the Accumulo folks did for Kuper, too, saying, "I can file that bug for you." We can be inclusive-or rather than exclusive-or about it, you know? That's how I figure it.

* Those products were CityDesk, Copilot, and FogBugz -- this was before Kiln, Stack Overflow, Trello, and Glitch.

Thanks to Lindsey Kuper and Jillian C. York for sparking this post, and thanks to azurelunatic for making sure I got Dreamwidth details right.

Filed under:

(1) : How Do We Encourage Technologists in the Public Interest?: As I mentioned when the Recompiler interviewed me, my inspirations and role models in technology are technologists who serve the public interest. The person who introduced me to free and open source software, Seth Schoen, is a kind teacher and a rigorous thinker who deploys his software engineering expertise at the intersection of technology and activism. I was lucky enough to meet the right people early in my career so I see public interest technology as a desirable and viable career path AND something you can integrate into a career that doesn't focus on nonprofit/government work -- but not enough people know about it, and not enough institutions encourage it.

How do we help encourage and employ more Seths, more Bruce Schneiers, more Eleanor Saittas, more Kelsey Gilmore-Innises? If you were to say "Sumana, that's a pretty infosecurity-centric list there, what about people who are more about analytics to enable policy work, or the web developers at 18F, or --" then I would agree with you! This is a broad and deep field, and thus a broad and deep question.

Again and again, we were told that public interest organizations and government will not succeed if they do not quickly figure out how to better harness the wave of innovation sweeping the world, and that one key element of that challenge will be to implement more effective strategies for developing and integrating technologists into relevant organizations and projects.
That is from A Pivotal Moment: Developing a New Generation of Technologists for the Public Interest, a new report that aims to help philanthropists choose what to fund (and how) to make this change happen. This is not just a bunch of vague "let's grow the pipeline" stuff. The authors interviewed 60 experts, laid out 26 specific things we can do (many of which are already in progress), and made a bunch of recommendations. Section III, starting on page 10 (page 16 of the PDF), summarizes the interventions in five categories: interest cultivation, skill-building, recruitment and training, skill deployment, and growth and retention.

If you can influence decisions on grants or donations, or if you just want a framework for thinking about this problem and its solutions (and where your existing work sits in the ecology), check out the report.

Filed under:

(1) : Rough Notes for New FLOSS Contributors On The Scientific Method and Usable History: Some thrown-together thoughts towards a more comprehensive writeup. It's advice on about how to get along better as a new open source participant, based on the fundamental wisdom that you weren't the first person here and you won't be the last.

We aren't just making code. We are working in a shared workplace, even if it's an online place rather than a physical office or laboratory, making stuff together. The work includes not just writing functions and classes, but experiments and planning and coming up with "we ought to do this" ideas. And we try to make it so that anyone coming into our shared workplace -- or anyone who's working on a different part of the project than they're already used to -- can take a look at what we've already said and done, and reuse the work that's been done already.

We aren't just making code. We're making history. And we're making a usable history, one that you can use, and one that the contributor next year can use.

So if you're contributing now, you have to learn to learn from history. We put a certain kind of work in our code repositories, both code and notes about the code. git grep idea searches a code repository's code and comments for the word "idea", git log --grep="idea" searches the commit history for times we've used the word "idea" in a commit message, and git blame shows you who last changed every line of that codefile, and when. And we put a certain kind of work into our conversations, in our mailing lists and our bug/issue trackers. We say "I tried this and it didn't work" or "here's how someone else should implement this" or "I am currently working on this". You will, with practice, get better at finding and looking at these clues, at finding the bits of code and conversation that are relevant to your question.

And you have to learn to contribute to history. This is why we want you to ask your questions in public -- so that when we answer them, someone today or next week or next year can also learn from the answer. This is why we want you to write emails to our mailing lists where you explain what you're doing. This is why we ask you to use proper English when you write code comments, and why we have rules for the formatting and phrasing of commit messages, so it's easier for someone in the future to grep and skim and understand. This is why a good question or a good answer has enough context that other people, a year from now, can see whether it's relevant to them.

Relatedly: the scientific method is for teaching as well as for troubleshooting. I compared an open source project to a lab before. In the code work we do, we often use the scientific method. In order for someone else to help you, they have to create, test, and prove or disprove theories -- about what you already know, about what your code is doing, about the configuration on your computer. And when you see me asking a million questions, asking you to try something out, asking what you have already tried, and so on, that's what I'm doing. I'm generally using the scientific method. I'm coming up with a question and a hypothesis and I'm testing it, or asking you to test it, so we can look at that data together and draw conclusions and use them to find new interesting questions to pursue.


So I'll ask a question to try and prove or disprove my hypothesis. And if you never reply to my question, or you say "oh I fixed it" but don't say how, or if you say "no that's not the problem" but you don't share the evidence that led you to that conclusion, it's harder for me to help you. And similarly, if I'm trying to figure out what you already know so that I can help you solve a problem, I'm going to ask a lot of diagnostic questions about whether you know how to do this or that. And it's ok not to know things! I want to teach you. And then you'll teach someone else.

In our coding work, it's a shared responsibility to generate hypotheses and to investigate them, to put them to the test, and to share data publicly to help others with their investigations. And it's more fruitful to pursue hypotheses, to ask "I tried ___ and it's not working; could the reason be this?", than it is to merely ask "what's going on?" and push the responsibility of hypothesizing and investigation onto others.

This is a part of balancing self-sufficiency and interdependence. You must try, and then you must ask. Use the scientific method and come up with some hypotheses, then ask for help -- and ask for help in a way that helps contribute to our shared history, and is more likely to help ensure a return-on-investment for other people's time.

So it's likely to go like this:

  1. you try to solve your problem until you get stuck, including looking through our code and our documentation, then start formulating your request for help
  2. you ask your question
  3. someone directs you to a document
  4. you go read that document, and try to use it to answer your question
  5. you find you are confused about a new thing
  6. you ask another question
  7. now that you have demonstrated that you have the ability to read, think, and learn new things, someone has a longer talk with you to answer your new specific question
  8. you and the other person collaborate to improve the document that you read in step 4 :-)

This helps us make a balance between person-to-person discussion and documentation that everyone can read, so we save time answering common questions but also get everyone the personal help they need. This will help you understand the rhythm of help we provide in livechat -- including why we prefer to give you help in public mailing lists and channels, instead of in one-on-one private messages or email. We prefer to hear from you and respond to you in public places so more people have a chance to answer the question, and to see and benefit from the answer.

We want you to learn and grow. And your success is going to include a day when you see how we should be doing things better, not just with a new feature or a bugfix in the code, but in our processes, in how we're organizing and running the lab. I also deeply want for you to take the lessons you learn -- about how a group can organize itself to empower everyone, about seeing and hacking systems, about what scaffolding makes people more capable -- to the rest of your life, so you can be freer, stronger, a better leader, a disruptive influence in the oppressive and needless hierarchies you encounter. That's success too. You are part of our history and we are part of yours, even if you part ways with us, even if the project goes defunct.

This is where I should say something about not just making a diff but a difference, or something about the changelog of your life, but I am already super late to go on my morning jog and this was meant to be a quick-and-rough braindump anyway...

Filed under:

: Advice on Starting And Running A New Open Source Project: Recently, a couple of programmers asked me for advice on starting and running a new open source project. So, here are some thoughts, assuming you're already a programmer, you haven't led a team before, and you know your new software project is going to be open source.

I figure there are a few different kinds of best practices in starting and running open source projects.

General management: Some of my recommendations are the same kinds of best practices that are useful anytime you're starting/running/managing any kind of project, inside or outside the software world.

For instance: know why you're starting this thing. Write down even just a one-paragraph or 100-word bulleted list description of what you are aiming at. This will reduce the chance that you'll look up one day and see that your targeted little tool has turned into a mess that's trying to be an entire operating system.

And: if you're making something that you want other people to use, then check what those other people are already using/doing, so you can make sure you suit their needs. This guards against any potential perception that you are starting a new project thoughtlessly, or just for the heck of it, or to learn a new framework. In the software world, this includes taking note of your target users' dependencies (e.g., the versions of Python/NumPy that they already have installed).

Resources I have found useful here include William Ball's book on theatrical direction A Sense of Direction, Dale Carnegie's How to Win Friends and Influence People, Fisher & Ury's Getting To Yes, Cialdini's Influence: The Science of Persuasion, and Ries & Trout's Positioning: The Battle for Your Mind.

Tech management: Some best practices are the same kinds of habits that help in managing any kind of software project, including closed-source projects as well.

For instance: more automated tests in/for your codebase are better, because they reduce regressions so you can move faster and merge others' code faster (and let others review and merge code faster), but don't sweat getting to 100%, because there's definitely a decreasing marginal utility to this stuff. Travis CI is pretty easy to set up for the common case.

I assume you're using Git. Especially if you're going to be the maintainer on a code level, learn to use Git beyond just push and pull. Clone a repo of a project you don't care about and try the more advanced commands as you make little changes to the code, so if you ruin everything you haven't actually set your own work back. Learn to branch and merge and work with remotes and cherry-pick and bisect. Read this super useful explanation of the Git model which articulates what's actually doing what -- it helps.

Good resources here include Brooks's The Mythical Man-Month, DeMarco & Lister's Peopleware, Heidi Waterhouse's "The Seven Righteous Fights", Camille Fournier's blog, and my own talk "Learn Tech Management in 45 Minutes" and my article "Software in Person". I myself earned a master's in technology management and if you are super serious about becoming a technology executive then that's a path I can give more specific thoughts on, but I'm not about to recommend that amount of coursework to someone who isn't looking to make a career out of this.

Open source management: And some best practices are the specific social, product management, architectural, and infrastructural best practices of open source projects. A few examples:

If you're the maintainer, it's key to reply to new project-related emails, queries, bug reports, and patches fast; a Mozilla analysis backs up our experience that a kind, fast, negative response is better than a long silent delay. Reply to people fast, even if it's just "I saw this, thank you, I'm busy, will get to this in a few weeks," because otherwise the uncertainty is deathly and people's enthusiasm and momentum drip away.

Make announcements somewhere public and easily findable that say something about the current state of your project, e.g., about whether it's ready to use or when to expect it to be. This could even just be someplace prominent in your README when you're just getting started. This is also a good place to mention if you're going to be at any upcoming conferences, so people can connect to you that way.

Especially when it comes to code, docs, and bug/feature/task lists, work in the open from as early as possible, preferably from the start. Treat private work as a special case (sometimes a useful one when it comes to communication with users and with new contributors, as a tidepool incubates growth that can then flow into the ocean).

I am sad, as a FLOSS zealot, to say that you should probably be on the closed-source platform that is GitHub. But yeah, the intake funnel for code and bug contributors is easier on GitHub than on any other platform; unless you are pretty sure you already know who all the people are who will use and improve this software, and they're all happy on GitLab or similar, GitHub is going to get you more and faster contributors.

You are adjacent to or embedded in other programming communities, like the programming language & frameworks you're using. Use the OSI-approved license that the projects you're adjacent to/depending on use, to make reuse easier.

It's never too early to think about governance. As Christie Koehler of Authentic Engine warns, to think about codes of conduct, you also gotta think about governance. (The Contributor Covenant is a popular starting point.) If you can be under the umbrella of a software-related nonprofit, like NumFOCUS, that'll help you make and implement these choices.

Top reading recommendation: Karl Fogel's Producing OSS is basically the bible for this category, and the online version is up-to-date with new advice from this year. If you read Producing OSS cover-to-cover you will be entirely set to start and run your project.

Additionally: Fogel also co-wrote criteria for assessing whether a project "is created and managed in a sustainably open source way". And I recommend my own blog post "How To Improve Bus Factor In Your Open Source Project", the Linux Foundation CII criteria (hat-tip to Benjamin Gilbert), "build your own rockstars" by one of the founders of the Dreamwidth project, and "dreamwidth as vindication of a few cherished theories" by that same founder (especially the section starting "our development environment and how we managed to create a process and culture that's so welcoming").

Obligatory plug: I started Changeset Consulting, which provides targeted project management and release management services for open source projects and the orgs that depend on them. In many ways I am maintainer-as-a-service. If you want to talk more about this work, please reach out!

Filed under:

: Two OSCON Conversations, And A Trip Report Between Them: Conversation the last night of OSCON, reconstructed from memory:

"So, Neil Young --"
"The singer-songwriter?"
"Man, what a white guy name."
"Are you impugning Neil Young? That man sells organic eggs at the farmer's market in my hometown!"
"Are you sure they're organic? You sure he doesn't just get them from Sysco?"
"Sysco doesn't even sell organic eggs."
"Uh, actually Sysco does sell organic eggs."
"Yeah right. I bet it's, like, orgänic, with an umlaut, so it can get around the FDA rules on calling things 'organic'."
"Yeah, and that's also how they get around the rules on Appellation Contrôlée."
"Anyway, Neil Young has a son who really likes model trains, and so he does model train stuff, and he actually has multiple patents related to model trains."
"Patents? Is he part of the Open Invention Network? Is this a defensive patent portfolio against Big Train?"
"You mean Supertrain?"

picture of Sumana in front of a steam train in Melbourne, AustraliaIn honor of late-night wackiness, I have not actually fact-checked whether Neil Young has any model train patents, or whether he or Sysco sell organic eggs. Caveat lector et caveat emptor.

My last visit to OSCON was in 2011, when I had worked for the Wikimedia Foundation for under a year, and wanted to build and strengthen relationships with the MediaWiki and PHP communities. I remember not feeling very successful, and thinking that this was a conference where executives and engineers (who in many cases are not terribly emotionally passionate about open source) meet to hire, get hired, and sell each other things.

These days, it turns out, OSCON is basically aimed at me! Because I am an executive trying to sell my services (e.g. get hired on an as-needed basis) to engineers and executives who make or depend on open source -- including the passionate ideologues, the burned-out used-to-be-passionate folks, the pragmatists, and all manner of other types. Changeset Consulting was novel, relevant, and interesting to approximately everyone I spoke with. Also, in the intervening five years, I've grown in skill, stature, reputation, and network. So I had something interesting to say, and O'Reilly accepted a talk proposal of mine for the first time. I saw scores of acquaintances, friends, peers, and colleagues in the halls and session rooms this year; I know and am known, which helps me feel at home.

I'm grateful to Audra Montenegro at O'Reilly Media for her speaker support. She worked with O'Reilly to cover my flight plus two hotel nights in Austin, making it possible for me to attend OSCON. She and other O'Reilly folks paid and worked with White Coat Captioning to provide CART (live captions) for my talk, at my request. And I was concerned that talking about inessential weirdnesses and inclusivity in open source upped my risk of harassment, so she arranged for some extra security for me. I'm also grateful to Andy Oram, my session chair, for his careful pre-conference prep (including checking on my pronouns -- she/her, thanks!), and for running a written Q&A session at my request.

I shall carry with me several memories of this OSCON, such as:

But here's a conversation that I particularly find stays with me. I was on the expo floor, talking with an acquaintance, and a stranger joined our conversation. I'll anonymize this recollection and call him Cyclopes.

He heard about the consulting services I offer, which focus on short-term project management and release management for open source projects and for companies that depend on them -- maintainership-as-a-service, in short.

Cyclopes: "Can you come to my company and tell us that the way we're doing deployments is all wrong, and tell them we should do it my way?"
Sumana: "Well, if your company hires me, and I assess how you're doing deployments and I think it's wrong, and I agree with the approach you want, then yes."
Cyclopes: "Great!" [explains his preferred deployment workflow, with justification, and says that it's like bashing his head against a brick wall for him to try to convince the rest of his company to do it]
Sumana: [lightheartedly] "So it sounds like what you really want is more a sockpuppet or an actor! Which might be cheaper!"
Cyclopes: "Hmmmm! You know, that is kind of what I want!"
[we three jest about this]
Sumana: "But, in all seriousness, like, you could go aboveboard with this. You know, you have options -- fraud and deception, or actually trying to persuade the other people in your org .... or, this is a wild guess, have you kind of burned bridges by being really abrasive, and now they won't listen to you?"
Cyclopes: "Yeaaaaaaaaah that might be what's happened."
Sumana: "OK! That totally happens and you weren't the first and you won't be the last."
Cyclopes: "Like, I've sent some pretty flame-y emails."
[acquaintance nods in sad agreement; we are all sinners here]
Sumana: "Oh man, the emails I've sent. I am so embarrassed when I look back. But you can come back from this. You really can. If you demonstrate to those people in your org that you really want to repair those relationships with them, they will respond. Like, if you say to them, 'I know I burned bridges before, I'm sorry about it, can we talk about this problem,' and you actually try to listen to them about what they need and what their context is, what they're worried about and what problems they're trying to solve, they will work with you, so you can figure out something that works for everybody. There's a book about this, about negotiation, that's a really short, quick read, it helped me a lot: Getting to Yes by Fisher and Ury."
Cyclopes: "Let me write this down." [notes book title and author on the back of my business card]
Sumana: "There you go, some free consulting for you. It's totally possible."
Cyclopes: "I think I could use that, I'm ripe for that kind of personal transformation in my life."
Sumana: "Great! Please, seriously, let me know how it works out."

Memory is unreliable, but I cannot forget the speed of my diagnosis, nor that this guy literally said that he was ripe for the kind of personal transformation I was prescribing. It's no model train patent but I think I'm happy anyway.

Filed under:

: Zulip & Good Code Review: As Changeset Consulting I've recently done some tech writing work for the Zulip open source project (check out my pull requests for the nitty-gritty). And I've gotten to work with Tim Abbott, Zulip's maintainer, including taking his feedback and course-correction. Often, in the software industry, we pretend or assume a dichotomy between brutal clarity and kind vagueness, especially when it comes to criticizing other people's work. Getting to work with Tim has been a welcome and consistent reminder that you can be straightforward and respectful when you need to give negative feedback.

Here's an example: Tim reviewing a pull request. Check out how he starts by saying it looks good, and then offers suggestions on how to break the patch into logical commits -- and how he makes sure to explain why we want to do that (including a link to a document that explains the reasoning and customs in more detail). Tim also tells the code author that it's fine to deviate from his specific suggestions, but gives him some guardrails. Since rebasing can be tricky for people who haven't done it much, he even suggests some git commands and tools that'll make things easier, and offers to clarify if needed. And Tim wraps it up with a thank-you and a quick explanation about why he's being so rigorous in reviewing this particular patch (security considerations).

It's thoughtful, kind, clear, and collaborative. It's the seventh comment Tim's offered on this pull request, as the author's iteratively improved it, and it shows no hint of impatience. Good stuff.

If this has piqued your interest in Zulip, you might also like the roadmap and README. Also, Zulip's holding a sprint at PyCon US, June 2-5, in Portland, Oregon.

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,'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.


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.


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,

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:

: Recent Discussion on Unfairness in FLOSS Economics: I'm keenly watching the conversation on structural imbalances in funding and use of free and open source software. Nadia Eghbal's recent essay has garnered attention, and here I collect some additional posts and threads by others about this disparity in the economics of FLOSS:

I include above some pieces that, on the surface, are adjacent to this conversation rather than in it: on open data, on emotional burnout, on GitHub's tooling, on license compliance, on setting expectations about unmaintained projects. But I see these frustrations as -- like the injustice driving volunteer maintainers to step away -- coming from a fundamental perception of unfairness. Free and open source software makers will notice if there is no measure of reciprocity in an environment that pays lip service to gift culture.

My next step probably ought to be reading the work of Nobel Prize winner Elinor Ostrom: "groundbreaking research demonstrating that ordinary people are capable of creating rules and institutions that allow for the sustainable and equitable management of shared resources." I do hope so.

Filed under:

(3) : Announcing Changeset Consulting: I'm delighted to announce the launch of my new business. I am the founder of Changeset Consulting, LLC.

Changeset provides short-term project management services to free and open source software projects. Need to expedite the releases of new versions of software, write developer onboarding and user documentation, triage and respond to bugs, clean out the code review queue, or prioritize tasks for upcoming work? Changeset Consulting lightens the load on your maintainers.

Details about the services I offer, my past work, and useful resources I've made are at I'm seeking new clients and would love referrals.

For now the shop is just me, but I'm aiming to have enough income and work by summer 2016 to hire an intern or apprentice, and to eventually hire full-time staff. We'll see how it goes.

I highly recommend Galaxy Rise Consulting, the firm I hired to design my website. Much thanks to Shauna Gordon-McKeon, and to all the friends and family who encouraged me on my way here!

Filed under:

: Software In Person: In February, while coworking at the Open Internet Tools Project, I got to talking with Gus Andrews about face-to-face tech events. Specifically, when distributed people who make software together have a chance to get together in person, how can we best use that time? Gus took a bunch of notes on my thoughts, and gave me a copy.

Starting with those, I've written a piece that Model View Culture has published today: "Software In Person".

Distributed software-making organizations (companies, open source projects, etc.) generally make time to get people together, face-to-face. I know; I've organized or run hackathons, sprints, summits, and all-hands meetings for open source projects and businesses (and if I never have to worry about someone else's hotel or visa again, it'll be too soon).

Engineers often assume we don't need to explicitly structure that time together, or default to holding an unconference. This refusal to reflect on users' needs (in this case, the participants in the event) is lazy management. Or event organizers fall back to creating conferences like the ones we usually see in tech, where elite men give hour-long lectures, and most participants don't have any opportunities to collaborate or assess their skills. Still a bad user experience, and a waste of your precious in-person time.

Why do you think you're spending hundreds of thousands of dollars holding hackathons, sprint weeks, and conferences? And how could you be using that time and money better?

Subsections include "Our defaults", "Investing for the long term", "Beyond 'hack a lot'", "Grow your people", and "Setting yourself up for success". Thanks to Gus and to Model View Culture for helping me make this happen!

Filed under:

: How To Improve Bus Factor In Your Open Source Project: Someone in one of my communities was wondering whether we ought to build a new automated tool to give little tasks to newcomers and thus help them turn into future maintainers. I have edited my replies to him into the How To Build Bus Factor For Your Open Source Project explanation below.

In my experience (I was an open source community manager for several years and am deeply embedded in the community of people who do open source outreach), getting people into the funnel for your project as first-time contributors is a reasonably well-solved problem, i.e., we know what works. Showing up at OpenHatch events, making sure the bugs in the bug tracker are well-specified, setting up a "good for first-timers" task tag and/or webpage and keeping it updated, personally inviting people who have reported bugs to help you solve them, etc. If you can invest several months of one-on-one or two-on-one mentorship time, participate in Google Summer of Code and/or Outreachy internship programs. If you want to start with something that's quantitative and gamified, consider using Google Code-In as a scaffold to help you develop the rest of these practices.

You need to quickly thank and give useful feedback to people who are already contributing, even if that feedback will include criticism. A fast first review is key, and here's a study that backs that up. Slide 8: "Most significant barrier to engaging in onramping others is unclear communications and unfriendly community. Access to the right tools has some effect." Slide 26:

"Contributors who received code reviews within 48 hours on their first bug have an exceptionally high rate of returning and contributing.
Contributors who wait longer than 7 days for code review on their first bug have virtually zero percent likelihood of returning.
Showing a contributor the next bug they can work on dramatically improves the odds of contributing."
(And "Github, transparency, and the OTW Archive project" discusses how bad-to-nonexistent code review and bad release management led to a volunteer dropping out of a different open source project.)

In my opinion, building bus factor for your project (growing new maintainers for the future) is also a solved problem, in that we know what works. You show up. You go to the unfashionable parts of our world where the cognitive surplus is -- community colleges, second- and third-tier four-year colleges, second- and third-tier tech hubs, boring enterprise companies. You review code and bug reports quickly, you think of every contributor (of any sort) as a potential co-maintainer, and you make friendly overtures to them and offer to mentor them. You follow OpenHatch's recommendations. You participate in Google Summer of Code and/or Outreachy internship programs.

Mentorship is a make-or-break step here. This is a key reason projects participate in internship programs like GSoC and Outreachy. For example, Angela Byron was a community college student who had never gotten involved in open source before, and then heard about GSoC. She thought "well it's an internship for students, it'll be okay if I make mistakes". That's how she got into Drupal. She's now a key Drupal maintainer.

paper curlicues and other papercraft surrounding a copy of Norbert Wiener's Cybernetics Dreamwidth, an open source project, started with two maintainers. They specifically decided to make the hard decision to slow down on feature development, early on, and instead pay off technical debt and teach newcomers. Now they are a thriving, multimaintainer project. "dreamwidth as vindication of a few cherished theories" is perhaps one of my favorite pieces on how Dreamwidth did what it did. Also see "Teaching People to Fish" and this conference report.

Maintainers must review code, and that means that if you want someone to turn into a maintainer in your project, you must help them learn the skill of code review and you must help them get confident about vetoing and merging code. In my experience, yes, a good automated test suite does help people get more confident about merging changes in. But maintainers also need to teach candidates what their standards ought to be, and encourage them (many contributors' first thought when someone says "would you want to comaintain this project with me?" is "what? me? no! I'm not good enough!"). Here's a rough example training.

If you want more detailed ways to think about useful approaches and statistics, I recommend Mel Chua's intro to education psychology for hackers and several relevant chapters in Making Software: What Really Works and Why We Believe It, from O'Reilly, edited by Greg Wilson & Andy Oram. You'll be able to use OpenHub (formerly Ohloh) for basic stats/metrics on your open source project, including numbers of recent contributors. And if you want more statistics for your own project or for FLOSS in aggregate, the open source metrics working group would also be a good place to chat about this, to get a better sense of what's out there (in terms of dashboards and stats) and what's needed. (Since then: also see this post by Dawn Foster.)

We know how to do this. Open source projects that do it, that are patient with the human factor, do better, in the long run.

Filed under:

(3) : Recent Reading Responses: Data & Society (which I persist in thinking of as "that New York City think tank that danah boyd is in" in case you want a glimpse of the social graph inside my head) has just published a few papers. I picked up "Understanding Fair Labor Practices in a Networked Age" which summarized many things well. A point that struck me, in its discussion of Uber and of relational labor:

The importance of selling oneself is a key aspect of this kind of piecemeal or contract work, particular because of the large power differential between management and workers and because of the perceived disposability of workers. In order to be considered for future jobs, workers must maintain their high ratings and receive generally positive reviews or they may be booted from the system.

In this description I recognize dynamics that play out, though less compactly, among knowledge workers in my corner of tech.

This pressure to perform relational labor, plus the sexist expectation that women always be "friendly" and never "abrasive" (including online), further silences women's ability to publicly organize around grievances. Those expectations additionally put us in an authenticity bind, since these circumstances demand a public persona that never speaks critically -- inherently inauthentic. Since genuine warmth, and therefore influence, largely derive from authenticity, this impairs our growth as leaders. And here's another pathway that gets blocked off: since since criticizing other people/institutions raises the status of the speaker, these expectations also remove a means for us to gain status.

Speaking of softening abrasive messages, I kept nodding as I read Jocelyn Goldfein's guide to asking for a raise if you're a knowledge worker (especially an engineer) at a company big enough to have compensation bands and levels. I especially liked how she articulated the dilemma of seeking more money -- and perhaps more power -- in a place where ambition is a dirty word (personally I do not consider ambition a dirty word; thank you Dr. Anna Fels), and the same scripts she offers for softening your manager's emotional reaction to bargaining.

I also kept nodding as I read "Rules for Radicals and Developer Marketing" by Rachel Chalmers. Of course she says a number of things that sound like really good advice and that I should take, and she made me want to go read Alinsky and spend more time with Beautiful Trouble, but she also mentions an attitude I share (mutatis mutandis, namely, I've only been working in tech since ~1998):

I've been in the industry 20 years. Companies come and go, relationships endure. The people who are in the Valley, a lot of us are lifers and the configurations of the groups that we're allied to shift over time. This is a big part of why I'm really into not lying and being generous: because I want to continue working with awesome, smart people, and I don't want to burn them just because they happen to be working for a competitor right now. In 10 years' time, who knows?

Relationships, both within the Valley and with your customer, are impossible to fake, and is really the only social capital you have left when you die.

No segue here! Feel the disruption! (Your incumbent Big Media types are all about smooth experience but with the infernokrusher approach I EXPLODE those old tropes so you can Make Your Own Meaning!)

Mark Guzdial, who thinks constantly about computer science education, mentions, in discussing legitimate peripheral participation:

Newcomers have to be able to participate in a way that's meaningful while working at the edge of the community of practice. Asking the noobs in an open-source project to write the docs or to do user testing is not a form of legitimate peripheral participation because most open source projects don’t care about either of those. The activity is not valued.
This point hit me right between the eyes. I have absolutely been that optimist cheerfully encouraging a newbie to write documentation or write up a user testing report. After reading Guzdial's legitimate critique, I wonder: maybe there are pre-qualifying steps we can take to check whether particular open source projects do genuinely value user testing and/or docs, to see whether we should suggest them to newbies.

Speaking of open source: I frequently recommend Dreaming in Code by Scott Rosenberg. It tells the story of the Chandler open source project as a case study, and uses examples from Chandler's process to explain the software engineering process to readers.

When I read Dreaming in Code several years ago, as the story of Chandler progressed, I noticed how many women popped up as engineers, designers, and managers. Rosenberg addressed my surprise late in the book:

Something very unusual had happened to the Chandler team over time. Not by design but maybe not entirely coincidentally, it had become an open source project largely managed by women. [Mitch] Kapor [a man] was still the 'benevolent dictator for life'... But with Katie Parlante and Lisa Dusseault running the engineering groups, Sheila Mooney in charge of product management, and Mimi Yin as the lead designer, Chandler had what was, in the world of software development, an impressive depth of female leadership.....

...No one at OSAF [Open Source Applications Foundation] whom I asked had ever before worked on a software team with so many women in charge, and nearly everyone felt that this rare situation might have something to do with the overwhelming civility around the office -- the relative rarity of nasty turf wars and rude insult and aggressive ego display. There was conflict, yes, but it was carefully muted. Had Kapor set a different tone for the project that removed common barriers to women advancing? Or had the talented women risen to the top and then created a congenial environment?

Such chicken-egg questions are probably unanswerable....

-Scott Rosenberg, Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest For Transcendent Software, 2007, Crown. pp. 322-323.

I have a bunch of anecdotal evidence that projects whose discussions stay civil attract and retain women more, but I'd love real statistics on that. And in the seven years since Dreaming in Code I think we haven't amassed enough data points in open source specifically to see whether women-led projects generally feel more civil, which means of course that means here's where I exhort the women reading this to found and lead projects!

(Parenthetically: Women have been noticing sexism in free and open source software for as long as FOSS has existed, and fighting it in organized groups for 15 or more years. Valerie Aurora first published "HOWTO Encourage Women in Linux" in 2002. And we need everyone's help, and you, whatever your gender, have the power to genuinely help. A man cofounded GNOME's Outreach Program for Women, for instance. And I'm grateful to everyone of every gender who gave to the Ada Initiative this year! With your help, we can -- among other things -- amass data to answer Scott Rosenberg's rhetorical questions. ;-) )

Filed under:

: The Continuing Adventures (Transitioning From Intern To Volunteer): 2014 WikiConference USA (Group F) 25 By now dozens of women have stepped into open source via Outreach Program for Women, a paid internship program administered by the GNOME Foundation. I recently asked several of them whether they had been able to transition from intern to volunteer.*

Are you succeeding at continuing to volunteer in your open source project? Or are you running into trouble? I'd love to know how people are doing and whether y'all need help.

When you were an OPW intern, you had a mentor and you had committed to a specific project for three months. Volunteering is freer -- you can change your focus every week if you want -- but the training wheels are gone and you have to steer yourself.

(I bet Google Summer of Code alumni have similar experiences.)

I got several answers, and in them I saw some common problems to which I suggest solutions.

  1. Problem: seems as though there are no more specific tasks to do within your project. Solutions: ask your old mentor what they might like you to do next. If they don't respond within 3 days, repeat your question to the mailing list for your open source project. Or switch to another open source project, maybe one your friends are working on!

  2. OPW mentors and interns at Wiki Conference USA 2014 Problem: finding the time. Solutions: set aside a weekly appointment, just as you might with a therapist or an exercise class. Pair up with someone else from the OPW alum list and set yourself a task to complete during a one-hour online sprint! Or if you know your time is being eaten up by your new job, set yourself a reminder for 3 months from now to check whether you have more free time in December.

  3. Problem: loneliness. Solutions: talk more in the #opw chat channel on GNOME's IRC ( Use and and to find get-togethers in your area, or launch one using and

  4. Karen Sandler, GNOME and OPW advocate. Problem: motivation. Solutions: consider the effects you're having in the world. Or focus on the bits of work you enjoy for their own sake, whatever those are. Or teach others the things you know, and see the light spark in their eyes.

These are tips for the graduating interns themselves; it would be good for someone, maybe me, to also write a list of tips for the organizers and mentors to nurture continued participation.

* OPW also provides a list of paid opportunities for alumni.

Filed under:

(10) : I'm Leaving My Job At The Wikimedia Foundation: (Music for this entry: "You Can't Be Too Careful" by Moxy Früvous; "Level Up" by Vienna Teng; "Do It Anyway" by Ben Folds Five; "Teenagers, Kick Our Butts" by Dar Williams.)

I've regretfully decided to leave the Wikimedia Foundation, and my last day will be September 30th.

I've worked at WMF since February 2011, so I've seen the Foundation grow from 70 to 214 people. It's the best job I've ever had and I've grown a lot. And my team and my bosses are tremendously supportive. In April I summarized my work achievements from the past four years and I remain proud of them. Most recently, I'm proud of co-mentoring Frances Hocutt, who's about to turn her energies to Growstuff API development (with help from your donations).

But I want to redefine myself and grow in new directions, as a maker and activist. Wikimedia has 13 years of legacy code and thousands of vocal stakeholders, and WMF has one office, in San Francisco. I'm a junior-level developer (I'm a much better software engineer than I am a coder) but don't want to move to San Francisco, where we (understandably) prefer to have junior devs onsite. And I'd like to try out what it's like to get better at making software, to have more of a blank slate and perhaps less of a public spotlight, to work face-to-face with a team here in New York City, and to exclude destructive communication from my life (yes, there's some amount of burnout on toxic people and entitlement). One of the things I admire about Wikimedia's best institutions is our willingness to reflect and reinvent when things are not working. I need to emulate that.

I remain on the board of directors of the Ada Initiative, which aims to close the gender gap in Wikimedia and other open culture/source projects. (Please donate.) And I don't see any way I could stop being a Wikimedian and pursuing the mission. You'll see me as User:Sumanah out on the wikis.

After I wrap things up at Wikimedia Foundation, I'll be privileged to spend six weeks at Hacker School, concentrating on learning how to crank out websites and fiddling with web security, and then in late November I'll be meeting other South Asian geek feminist women at AdaCamp Bangalore. Aside from that I'm open to new opportunities, especially in empowering marginalized groups via open technology.

"Level Up" by Vienna Teng. ("If you are afraid, come out.") And heck, why not, a Kira Nerys fanvid I love, set to "Shake It Out" by Florence + The Machine. ("So tonight I'm gonna cut out and then restart.")

Filed under:

(1) : Case Study of a Good Internship: I'm currently a mentor for Frances Hocutt's internship in which she evaluates, documents, and improves client libraries for the MediaWiki web API. She'll be finishing up this month.

I wanted to share some things we've done right. This is the most successful I've ever been at putting my intern management philosophy into practice.

Setting up an internship on a strong foundation makes it a smoother, less stressful, and more joyous experience for everyone. I've heard lots of mentors' stories of bad internships, but I don't think we talk enough about what makes a good internship. Here's what we are doing that works. You?

(P.S. Oh and by the way you can totally hire Frances starting in September!)

Edited 2 October to add: Frances listed "[s]ome particularly useful approaches and skills" that made her internship work.

Filed under:

(6) : Why Job Titles Matter To Me: A friend asked for help in thinking about job titles and job descriptions, and said she was specifically interested in how to think about them and whether they matter at all. I gave her some thoughts, from my experience, and thought I might share them here.

I think job titles *do* matter, in a few different dimensions. Here are the three major ones.

  1. giving correct expectations about you (your skills, your expertise, your influence within your org, your seniority, your independence as a decision-maker) to people outside your company/org, who use that metadata as a hint to treat you appropriately (invite you to give talks, recruit you, ask you suitable questions when they meet you, introduce you to other resources, ask for introductions, offer to sell things to your org or buy things from your org or otherwise partner with your org, praise or criticize your org)
    (A subset of these goals: demonstrating for future recruiters/employers a particular career progression on your résumé.)

  2. giving correct expectations about you to people inside your org who don't already know you, e.g., new hires and Human Resources, so they treat you appropriately (assume you know/don't know certain skills and domains, take your advice seriously, invite you to the right brownbags and hackdays, put you on certain career ladders, ask whether you'd be interested in taking on a new project)

  3. hint to yourself about what you should focus on or what you/your org values (e.g., "senior" implies mentorship/stewardship, "reliability" or "performance" or "happiness" tells you what goal to focus on, "researcher" or "manager" or "analyst" or "nurturer" tells you what methods/skillsets you should be employing) -- this should be Part Of A Complete Breakfast, I mean, Job Description

Some people find that job titles do not matter to them. I posit that those people believe, or act as though they believe, that it is unimportant to provide additional easily-graspable metadata about their own work-selves to strangers or colleagues (I could imagine lots of reasons that this would feel unimportant) -- or that they already know what they need to be working on and do not need additional guidance-reminders.

In the current US software industry, sometimes you run across deliberately informal titles - God/Guru/Ninja/Wizard/Grunt/Thing-doer/Goddess/Mistress/etc. I don't quite feel up to the task of laying out the particular signals one THINKS one is sending, and the signals one actually IS sending, with those job titles. This feels like Kate Losse territory. Here, as with so many other human relationships, you might run into the very natural desire to make a joke out of it to elide all the tension and status play. And I understand that. When I got married, Leonard and I had a HARD TIME getting used to the words "husband" and "wife"! To ease into them, we mispronounced them or banged them together with other words, so, e.g., he was a "funband" and I was a "funwife". I feel like new formal job titles can be like that too, uncomfortable, like "one size fits all" clothes.

Sometimes silly job titles signal to others, "we value whimsy/insider cliquishness more than we value clear communication about tasks and roles with people outside our internal culture."

So if someone dismissively says that job titles don't matter, I suggest you tack on a silent "to them right now" when you interpret their statement.

Filed under:

: You Can (Sometimes) Negotiate When Being Laid Off: Some of the details escape me now, but people may still find use in the tale of how I succeeded in negotiating a counterproposal when I got laid off several years ago.

Once upon a time, I was working as a project manager. The owners of the firm laid off some people, and then laid off more. The next time that I saw them sitting in the conference room looking unhappy for an entire Friday, I knew what would probably happen next.

One of them came out to ask for me. I came in and sat down. One of them started off with a sentence very much like, "So you know that we haven't been doing so well lately."

"Am I being laid off?" I asked.

They said yes.

"I have a counterproposal," I said.

They were surprised.

I explained that I was at that moment managing projects that would -- if managed properly -- have three billable deliverables finished within the next six weeks. If they laid me off immediately, they would not have nearly enough management bandwidth to ensure on-time completion. They needed the cash, so they really wanted to hit those deadlines.

So I offered to work at half my salary for the next six weeks and do my damndest to hit those deadlines.

They had to think about it, so I went back to my desk and started packing up my stuff. Slowly. My colleagues consoled me. More colleagues went into that room and came out and started putting their personal misc into boxes.

And then they left, and one of the owners took me aside and basically said yes, so I started unpacking.

On Tuesday, I think, I sat down with one of the owners briefly to talk him through the numbers. I showed him how much it would cost to pay out my vacation as a lump sum versus keeping me on for those several days, and one other variation I don't remember. I believe they chose the lumpsum option for some accounting reason.

I got two of the three projects done on time. I got a little more time and money and healthcare coverage before I had to figure out the next thing. And I got some experience negotiating, not just at the start of a job, but at the end of it.

Filed under:

(2) : A Change Of Roles: I did open source community management for MediaWiki for about three years. At first, in 2011, I was an individual contributor (see my February 2012 post "What Does A Volunteer Development Coordinator Do?"). After several months I became the team lead, and then about two years ago Wikimedia Foundation promoted me and I started managing my team. Dozens of people hit reply-all to congratulate me in messages I still treasure. (You have a "yay" folder too, right?)

I hired our new bug wrangler and our new volunteer coordinator. I got Wikimedia Foundation participating in the Outreach Program for Women paid internships, and we got way better at new developer intake in general. I introduced the Friendly Space Policy for WMF technical events (and we sure ran a lot of them). I introduced some innovations that took, and a few that didn't. When you fix one bottleneck you notice the next one -- that's the nature of bottlenecks -- and so we worked on harder and harder problems.

By external measures I was doing really well. But my management style does a lot better face-to-face, and I found it tiring to try to manage logistics and emotional nuance almost entirely via text - managing up, down, and sideways. And community management is often a customer service job with big gobs of emotional labor (example). By late 2013, I'd sort of plateaued; I wasn't learning as much and as fast as I wanted.

Hacker School gave me an opportunity to reset and to look at Wikimedia with new perspective, and to reawaken my interest in hands-on technical contribution and learning. I came back to a WMF that had just renewed its search for a FLOSS-savvy technical writer with programming skills. And, fortunately, my colleague Quim Gil was willing to make his interim position permanent, and keep on leading the team. So, as of about a month ago, I'm Senior Technical Writer at the Wikimedia Foundation.

And it's great. I've taken our Requests for Comment process in hand, started drafting improved architecture guidelines (not there yet) and our first unified set of performance guidelines, and started planning improved API documentation. And I've been learning bunches. I've learned enough to summarize REST and SOA and HTML templating systems as they relate to MediaWiki. I've learned how our caching layers work and how the new parser works. And I get to translate what I learn into prose and visuals to teach others, and I get to mentor intern Frances Hocutt as we both learn about the MediaWiki web API. For the last several weeks I've concentrated on understanding big things like how SOA will change our architecture, but post-PyCon I'm raring to code more; I'm looking forward to pair programming with Frances.

I feel so fortunate to have such a strong team. (This is one reason you hire people who could replace you - it gives you more room to change.) And I'm grateful to be at Wikimedia Foundation, an organization that nurtured and promoted me, gave me a three-month sabbatical to go to Hacker School, and helped me find different valuable work to do when I came back changed.

The two big problems I worked on as MediaWiki's community manager: inculcating empathy in others, and designing processes that scale. I made a dent in both, and I'll come back to them, and to management in general, in some future when I'm yet another Sumana, changed again.

Filed under:

: UX Is A Social Justice Issue: On March 25th, I had the honour of addressing the Code4Lib conference as their opening keynote speaker. My topic: "User Experience Is A Social Justice Issue".

....Maybe another way of thinking about it is, when we're building services for people, we often have a lot more practice seeing from the computer's point of view than seeing from another person's point of view. In tech I think we understand how to build arteries better than we understand how to build capillaries....

They liked it! You can enjoy it too. After a very short introduction, my speech goes up to 30:45 in the YouTube video (embedded below). It'll be on the Internet Archive & Wikimedia Commons as well.

You can read the script I read from, annotated with citations, links to resources, and links to tweets and blog posts about the talk. (I aim to get a true transcript sometime soon and update that wiki page accordingly.)

Thanks to the Code4Lib community for inviting me, and to those who helped me with my talk: Coral Sheldon-Hess, Mel Chua, Andromeda Yelton, Bess Sadler, Emma Molls, Leonard Richardson, Jared Zimmerman, and Sky Croeser.

Filed under:

: Loop: I just reread Lee Iacocca's autobiography, in which he mentioned the loop apprenticeship he did when he first got to Ford. Fog Creek's SMTP and the vaunted Procter & Gamble apprenticeships are a bit like this.

Mel wrote:

Reading about cognitive apprenticeships brings up all sorts of fun moments. For instance, the ideal way to design an apprenticeship experience is to have students do global tasks early on, then local tasks later. Do something that lets them see the big picture (assemble a whole dress) first before focusing on detailed parts (cut out a piece for a dress)....

* teach release engineering first, instead of programming

What would a real open source software apprenticeship flow look like? May First/People Link has an idea, around systems administration. Anyway, I know Mel probably has a zillion thoughts on this and I look forward to reading her thesis, but it's just on my mind and I thought I'd note it down so I can get to sleep.

Filed under:

: Open Source Jobs (We're Hiring): The Wikimedia Foundation, which employs me, is hiring, a lot. We need your help to:

    Wikimedia Foundation 2013 All Hands Offsite - Day 1 - Photo 23, by Fabrice Florin, for the Wikimedia Foundation (Wikimedia Foundation) [CC-BY-SA-3.0 (], via Wikimedia Commons
  1. write code to try new ways to encourage people to edit Wikipedia (Growth engineer)
  2. keep our users' data safe (operations security engineer)
  3. make sure our designers and multimedia engineers build the right things (multimedia product manager)
  4. help other Wikimedians figure out how to design their outreach and mentoring initiatives better and evaluate them for effectiveness, so we learn what works (program evaluation community coordinator)
  5. automate more of the systems that help developers test new code to find bugs early (Test Infrastructure Engineer)
  6. like 14 other jobs, seriously, we're hiring a lot

And of course everything you make at the Wikimedia Foundation is freely licensed, so you can suggest your buddies use it to solve their problems, write public blog posts about it, talk about it at parties and conferences, and link to it on your résumé. Isn't open source rockin'?

(Many WMF workers, including me, telecommute. You might also like our Pluralism, internationalism, and diversity policy.)

Some other places that make open source software or free culture and are hiring: Linaro, MongoDB, Participatory Culture Foundation, CollectionSpace, Harvard Humanitarian Initiative, Mozilla, Kaltura, Boundless, Acquia, OpenStack-using companies, Varnish Software, Red Hat, InkTank, wikiHow, the libraries and similar institutions seeking Wikimedians/Wikipedians in Residence, Canonical, Collabora, the Linux Foundation, Eucalyptus, New York Public Library Labs, Pro Publica, Nebula, the Electronic Frontier Foundation, the Open Knowledge Foundation.

That's just a fraction of who's hiring. You can check the FSF jobs board, OPW's list and the liberationtech-jobs mailing list for more.

If you're looking specifically for internships, the OpenHatch list, Google Summer of Code, and Outreach Program for Women should help you.

This is a followup to a similar post I made in late 2012. Erik Moeller and Sumana Harihareswara at Hackathon Mumbai 2011 -18, by Victorgrigas (Own work) [CC-BY-SA-3.0 (], via Wikimedia Commons

Filed under:

(2) : Open Source Careers: Yesterday I spoke at an OpenHatch Open Source Comes to Campus event on the other side of the country. The organizers set up a video conference and asked me, and two other people who work in open source, to talk about our careers. (If you are running an event like this, or teach a class or something, I'd probably be happy to do this for you as well.) Some things we mentioned:

By the way, I should also link to this one-hour video on the realities of open source careers. Cynical in some ways, and I particularly disagree with the speaker on the matter of references; you should not assume that the hiring manager isn't going to directly call the references you provide, and ask them interesting questions. And the emphasis on unpaid work can go awry, and I started rolling my eyes at the oversimplifications halfway through (e.g., the idea that an employment contract means literally nothing). But the talk also has some truths that students don't hear often enough.

Filed under:

: Hidden Jewels of the RFC or PEP Process: I've been looking into other open source projects' processes for making big architectural changes, to help improve MediaWiki's process. Some have Requests for Comment processes, separate from normal bug/enhancement tickets. Some don't. Some have voting, some have a Benevolent Dictator For Life making the decision. And so on and so on. (This is where I get to use my bachelor's in political science!)

I have come across a few fun documents in this quest:

Filed under:

: Tourists: What do you know about pipe organs?

Several years ago, all I knew about organs I'd learned from a few pages in Cryptonomicon comparing them to vacuum-tube computers. And I liked their sound. I was a regular attendee at the Community Church of New York at the time, and CCNY featured organ music in its Sunday service.

One day I heard that they were fundraising for organ upkeep. To help people see what needed doing and why, someone led a small group of us on a guided tour of the organ. I got to see how its parts related to each other, how all the inputs turned into the sound we enjoyed.

Any sysadmin or manager trying to persuade others to invest in long-term infrastructure should consider a similar tactic. Give your stakeholders a tour of your system's anatomy, so they can appreciate it.

Filed under:

: My Family And The Ada Initiative: Please join Leonard and me in donating to the Ada Initiative. Why? Let me tell you a story, and then a surprise.

My parents came to the US from Karnataka, in south India, in the 1970s, and they were lonely. They spoke Kannada and English and Farsi and Hindi and Sanskrit, but Kannada was their mother tongue, and they arrived in Oklahoma and found no Kannadiga community to speak of. (Go ahead and groan. My dad passed on his love of terrible puns to me.)

An Amerikannada envelope and my parents' wedding photoI'm not saying they were the first Kannada speakers in the US. There were definitely already Kannadigas in the US in the 1970s. Indians had been immigrating here for decades.* There were letters and long-distance phone calls and occasional visits, a few families getting together, the adults laughing and swapping tips in Kannada while kids ran around. But the Kannada-speaking diaspora was scattered and had no central place to talk with each other. A bunch of people who shared a characteristic, but not really a community.

So my parents did some community organizing, in their spare time, in between working and raising my sister and me. How did they get Kannada speakers together? They started "Kannada Koota" local organizations (like user groups). "Koota" means "meeting" in Kannada. They basically started a grassroots network of Kannadiga meetups. How did they get these folks talking to each other, all across the country? They started a bimonthly magazine, Amerikannada, and ran it for 7 and a half years, until their money and energy ran out. It had great fiction, and articles from the literary magazines back home. And it included ads for those Kannada Koota meetups, "how I started a Kannada Koota" articles, and tutorial exercises for "how to learn Kannada", for parents to teach their kids. My parents were sharing best practices, talking meta, inspiring people all over.

I didn't really know that, as a kid. As my parents processed subscriptions, recruited articles and ads, wrote, and edited, my sister and I stapled, stamped, glued, and sealed bits of paper in languages we couldn't quite yet read. We had a rubber stamp with the logo: a griffin-like creature, half-lion, half-bald eagle. I gleefully deployed those magical bulk-mail stickers, red and orange and green with single-letter codes, and piled envelopes into burlap sacks and plastic bins for the frequent trips to the post office.

An Amerikannada envelope, my dad's employee badge at a nuclear power station, and the Rajyotsava award he received for service to the Kannada languageIt was always my Dad who took the Amerikannada mail to the post office. He was strong in those days, heaving the great bags of mail like an Indian Santa Claus (mustache yes, beard no) alongside the blue-uniformed workers on the loading dock, the part of the post office most people never use or even see. My sister and I came along, not to help -- how could we? -- but to keep my Dad company.

At home, while toying with BASIC on a PC Jr, I overheard the shouted long-distance phone calls in mixed Kannada and English. Stuff like "Go ahead and give me the directions to the venue, and I'll tell it to Veena." or "Well you know who you should talk to? Raj is going to be over there around then...." Weekend after weekend I spent reading science fiction in some corner at a Kannada Koota.**

My father receiving the Rajyotsava award from the government of Karnataka. From Kannada WikipediaThe funny thing is that I thought I was rebelling against my parents by taking the path I did. I majored in political science at Berkeley instead of engineering, and fell in with open source hippies. I used AbiWord on Caldera Linux to write papers about nineteenth-century American political theory and naturalization rates among Indians in Silicon Valley. I fell away from coding and saw that other things needed doing more urgently: tech writing, testing, teaching, marketing, management.

And here I am now, a community organizer like them, finally appreciating what they did, what they made, what they gave up. My dad had to work to support us; he couldn't edit Amerikannada full-time, even if that would have been a better use of his talents, and a greater service to the world. My parents couldn't find enough ads and subscribers to pay for the cost of keeping the magazine going. I appreciate WordPress and PayPal all the more because I see that Amerikannada folded (partly) for the lack of them.

My momWhat if one of my parents had been able to bring in income from the community we were building? What if it had been sustainable?

Today, the community that I most identify with is that of women in open source and open culture. We've talked to each other in pockets and locally for decades - hats off to LinuxChix and VividCon, for instance - but in the last few years, The Ada Initiative has brought us more resources, a stronger community, and faster progress than ever. And this is possible because the Ada Initiative's staff is full-time.

So, here's the surprise: Leonard and I will match every donation to the Ada Initiative up to a total of USD$10,000 until midnight August 27th PDT, one week from today. Yes, again. And this time, if the community matches the full amount, we'll chip in an extra thousand dollars.

The Ada Initiative's work is useful in our own lives. When I needed an anti-harassment policy for my workplace's technical events, and when Leonard wanted resources to advise his technical communities on diversity, we consulted the Ada Initiative's resources. AdaCamp brings together, teaches, and inspires women from all over, including me. And the network I found via the Ada Initiative helped me write a keynote speech and respond to unwanted touch at a hackathon.

But more than that, we know that we're improving our world and helping science fiction, open source, and Wikipedia live up to our values. We believe in inclusiveness, compassion, empowerment, and equal and fair treatment for all, and the Ada Initiative opens the doors for more women to get to enjoy those values in the places we love.

And my parents taught me that I should give back. It feels so much better to give back than to give up.

* One couple who moved from Gujarat to California in 1958 had a son who's now a Congressman.

** Nowadays I get to be the only Kannadiga at science fiction conventions.

Filed under:

(1) : Tips for New Summer Interns: Three tips to help new Google Summer of Code applicants and interns, some of which all remote workers could stand to remember:

  1. Never let yourself get stuck on a technical question or problem for more than half an hour. Take a break, ask questions in IRC or a mailing list, find a technical book to read like The Architecture of Open Source Applications, look at some other codebase to see how they do it, eat a meal, or do something else, then come back to the problem.
  2. Never let yourself get stuck waiting for someone's reply for more than 2 business days (Monday through Friday). Escalate -- ask your mentor. If your mentor isn't helping, ask your org admin. If the org admin isn't helping, ask on the GSoC discussion forum, or email Carol Smith.
  3. Ask yourself at the start of every day: what did I accomplish yesterday? What will I try to do today? What are the obstacles I think I will run into? If you ask yourself those three questions and answer honestly -- especially if you let your mentor and team know the answers -- then you will prevent long delays and help keep your morale up.
Filed under:

(3) : Open Tech New York City: Yesterday I delivered a reasonably well-received talk at Open Tech NYC in which I introduced the crowd to their New York open tech neighbors. That is, I explained the four freedoms that define what make software truly free and open, and I gave examples of NYC people and institutions who make or use open culture and open knowledge, open data, open source software, open formats and open hardware.

Here are a bunch of links!

I hope the people listening understood that I was just offering a sample of the organizations in the five boroughs that work on or use open stuff! I opened and ended my speech with some thoughts about love and sharing (and how being a free software person is like or unlike being a vegan), which I reused from "A Slightly Disjointed (Due To A Five-Day Cold) Musing On Open Source, Fear, Motivation, And Witnessing", where I discuss my experience with the open source GNOME desktop environment.

During the coffee breaks and lunch, I also spread the word about Outreach Program for Women and Google Summer of Code internships available this summer; application deadlines are around May 1st.

Thanks to the sponsors and organizers of Open Tech NYC 2013. I enjoyed it despite getting over a cold, and appreciated the chance to learn from and chat with a variety of people interested in open stuff.

Update: Video is up.

Filed under:

: What Systems Administrators Do: I hope you'll read two blog entries I just wrote, whether you consider yourself a "techie" or not. They're meant to explain why the recent Wikimedia data center migration was difficult and took a long time, and how our systems administration department has started being able to respond to problems faster, and prevent them. And I wrote them in the hope that non-programmers will be able to appreciate my colleagues' work.

From duct tape to puppets: How a new data center became an opportunity to do things right (using Puppet for configuration management).

How the Technical Operations team stops problems in their tracks (fixing crises and preventing them with Nagios, Graphite, & Ganglia for monitoring & profiling).

Sometimes non-sysadmins don't appreciate the work that sysadmins do, building and maintaining infrastructure so the rest of us can use websites without thinking about it. But it's important work and I hope these posts help Wikipedia and Wikimedia users recognize it.

Filed under:

(2) : We Are Hiring - You Too?: Wikimedia Foundation is hiring, a lot. We need your help to:

And of course everything you make at the Wikimedia Foundation is freely licensed, so you can suggest your buddies use it to solve their problems, write public blog posts about it, talk about it at parties and conferences, and link to it on your résumé. Isn't open source rockin'?

Some other places that make open source software and are hiring: Linaro, 10gen (makers of MongoDB), Participatory Culture Foundation, Balboa Park Online Collective, CollectionSpace, Mozilla, OpenStack, Red Hat, Canonical, Collabora. And you can check the FSF jobs board.

If you're hiring people to improve open source -- designers, tech writers, product managers, sysadmins, coders, etc. -- feel free to leave a comment. I know a few FLOSS-ish folks who are about to start looking and maybe I can direct them your way as well.

Filed under:

(1) : I Am A Software Developer: I arrived in San Francisco yesterday in just enough time to speed to Wikimedia Foundation headquarters and present:

Watch, live, via screensharing as a developer fixes a bug, including investigation, git commit, getting it reviewed and merged, and closing the Bugzilla ticket. Probably featuring Sumana Harihareswara. Great for newbies!
About 25 people watched the YouTube stream, which you can now view (it's about the first 20 minutes; the IRC log starts at 20:30:36). A copy of the video should get to Wikimedia Commons sometime in the next week.

A small part of me thought I was defrauding the viewers by masquerading as a developer. Because, sure, I fix user-visible strings and all, and I can read code okay, but (insert moving-the-goalposts here).

This morning, of course, I woke up too early from jet lag, and was listening to calming music, trying to get back to sleep. And then I realized that I hadn't fixed the second half of the demo bug. So I dragged myself upright and opened my laptop and made the fix.

Okay, now I'm a developer. An occasional, entry-level software developer, but one nonetheless. I viscerally believe that the ritual that brought me into that guild was not yesterday's commit, but today's.

Filed under:

(6) : Leonard And I Will Match Ten Thousand Dollars Of Your Ada Initiative Donations: Leonard and I met because of the open source movement. We owe our livelihoods to open source, and its values -- inclusiveness, compassion, empowerment, equal and fair treatment for all -- help make us who we are.

This is why he and I are pledging to match up to USD$10,000 of donations to the Ada Initiative made before November 1, 2012.

The Ada Initiative works to increase the participation of women in open technology and culture. They gave me the wording and support I needed to create Wikimedia Foundation's Friendly Space Policy for technical events, which helps everyone at a Wikimedia hackathon feel safer so they can concentrate on rockin' out. If you liked "Be Bold: An Origin Story", the keynote I delivered at Open Source Bridge this year, thank the Ada Initiative, whose advisors helped me shape it. Everyone who wants to grow the open source community benefits from the Ada Initiative's work, and so donating to TAI is like investing in a good piece of machinery; TAI's going to make my work easier for a long time to come.

Please join us in donating to the Ada Initiative, especially if you've also gotten a good career out of open source.

Filed under:

: Sometimes An Unconference Is The Wrong Choice: Now that I'm something of an expert on it, I have Opinions on how to structure a workshop or collaboration event for newbies. Summary of my answer:

We all want to avoid stultifying slide presentations, and if we preplan the schedule, we might choose irrelevant topics or activities. One alternative is Open Space Technology, which substitutes an alternative, more participatory event structure and nearly guarantees that no one will fire up PowerPoint. Some planners (and participants) think that all planned activities are per se useless, and that thus we should only do unconferences that follow an Open Space model, regardless of the event's audience. More often I run into new event planners who default to "we'll do an unconference" without thinking about whether that's the best tool for the job.

When people suggest removing traditional structure from collaboration events, I think of Mako Hill's research on why Wikipedia succeeded and other contemporaneous projects didn't (summary, audio and video). One reason is: even though the peer production model was unfamiliar and chaotic and new, the goal (an encyclopedia) was well-defined. In contrast, these other projects were trying to redefine both process and THE NATURE OF KNOWLEDGE CYBER COLLAB DISTRIBUTED ETC ETC: both process and outcome.

I think that workshops are kind of like that. You can either be innovative, groundbreaking, and inclusive in what you are doing or how you are doing it, but both, simultaneously, is very hard. (This is also an issue with Agile.)

If you are planning an event for people who already know and trust each other, and are good at public speaking and collaboration, and are experts in the field, then an unconference might work! But for newbies who are learning not just a new skill, but a new way of thinking? Give them a more familiar structure. (WisCon is an interesting example here. It's a massively multiplayer conference: anyone can suggest sessions or suggest themselves as copanelists or moderators. But a programming committee processes that input ahead of time into a great at-con schedule.)

This is tough for free culture ideologues, because one wants to "be the change you wish to see in the world", and do everything collaboratively, empoweredly, etc. But sometimes the ivy needs a trellis to grow on.

I think event organizers should consciously design space in the structure for breathing room. People get a lot out of the breaks, the hallway track, and unconference sessions. But I think it's rare to have a good hallway track without some interesting and structured stuff happening in the rooms just off the hallway.

Filed under:

(2) : Be Bold: An Origin Story: I'm getting very positive reviews for my opening keynote from Open Source Bridge.

Video (starts around 6:00), speaker's notes (text that needs updating to match the audio).

Filed under:

: Conference Seasoning: I'm speaking at Open Source Bridge - June 26–29, 2012 - Portland, OR You know you're traveling too much when you completely stop updating the "where I'm going to be" feeds (example).

Regardless: I'll be in San Francisco starting late today, and then in Portland on Monday the 25th, the day before I give the opening keynote address at Open Source Bridge. My tentative title: "Be Bold."

Wikimedians are giving several other talks during the conference:

The Wikimedia Foundation is also sponsoring the Friday unconference day, and will host a hacking table that day as well as (I hope) the Tuesday "Hacker Lounge Project/Community Night."

Wikimania 2012 logo Then, I'll be in Washington, DC, July 10th-15th for Wikimania, especially the pre-conference Hackathon. I'm happy to announce that WMF is partnering with OpenHatch to make the pre-Wikimania hackathon even more useful. OpenHatch is planning and running the novice-focused half of the event, with trainings and projects to help people learn how to hack Wikimedia technology.

I'm leading at least two talks at Wikimania:

I say "at least two" because who knows whether folks will rope me into moderating a panel, or doing some stand-up comedy.
Filed under:

(1) : Challenge: Wikimedia Foundation is hiring a leader for volunteer software testing. I have ideas on what this person should do and how to do it* -- indeed, this position reports to me -- but more than that, I have ideas about what kind of person I need to find.

I need someone who has skills in open source contribution, who gets the wiki and open source way. Even if the person lives in San Francisco -- which they don't have to -- they have to collaborate well remotely, with volunteers and other colleagues. And I seek someone who has the focus and analytical skill one needs to test software, and the hospitable and generous temperament one needs to encourage and teach newbies.

I've been bookmarking lists of suggestions for ways to test, like You Are Not Done Yet and Falsehoods Programmers Believe About Names and its sequel on time. We've already started running online events for new testers. If talking like this is scratching an itch for you, even if you've never had a job title as a software tester, please apply. At least we'll have an interesting conversation.

* Had I worlds enough and time, I would start a retraining school that turned underpaid copyeditors into versatile and sought-after software testers. Proofreaders can already follow instructions and communicate effectively and deploy critical thinking skills while nitpicking, so they just need some guidance in learning some domain knowledge. (One of the great benefits of the modern technology industry is that it provides productive and lucrative channels for pedantry.) I do not have the time to do this for profit, but perhaps my Engineering Community Team can use this kind of arbitrage to recruit and train volunteers, give them some skills to put on their résumés, and get some more quality assurance.

Filed under:

(5) : A Local Maximum: By the way, I got promoted. It's quite an honor.

Wikimedia Foundation's new Engineering Community Team, which I lead, is a renaming of the TL;DR group. We've written a draft summary of our goals for July 2012-June 2013. There's so much to be done! (Of course, we're hiring.)

In open source, we share our vulnerabilities and our milestones, so of course my boss announced my promotion to a public mailing list. I was surprised and delighted when colleagues and contributors in my community responded to that announcement with congratulations, privately and publicly. It is as though they believe I am doing a good job! Take that, impostor syndrome.

I'm thinking about the thirty years of influences that got me here. As a teen, I volunteered for the Peace and Justice Network of San Joaquin County, and met my mentor John Morearty, whom I saw this past weekend. Before I knew Sam Hatch, and before I knew Seth Schoen, even, I knew John, a teacher who took his values seriously and was always ready to teach. He led volunteer communities that aimed for inclusiveness and viral change. He modeled grit, open-mindedness, and compassion, and I saw in his example that another world was possible, another mode of being. He wrote a fascinating memoir that you should check out, if you like twisty life stories.

John had twin sons, Mike and Brian. I got to meet Mike on Sunday. On Monday he got write access to Wikimedia Labs, Git, and Gerrit. I find this confluence pleasant yet dizzying, like the bushels of jasmine in John's garden. There's so much to be done, and the abundance of my world may yet provide. As John reminded me this weekend, we cannot build the new systems we need; we must cultivate them.

Filed under:

: Asymptomatic, Asymptotic: Last night I gave Leonard some alone time to work on a Constellation Games bonus story. I went to Ward III, a Manhattan bar that does bespoke cocktails. They have a menu of predesigned cocktails as well, but if you tell them, "I would love something bubbly with basil and lemon," they think about it and figure something out. I especially appreciate that they are perfectly fine with making interesting nonalcoholic drinks. I don't know a better place to get a bespoke mocktail.

Sunita Williams aboard the International Space Station, working with a biological and chemical substances detector, 2007, public domainWhile there, I read a bit of Making Software. One of its editors also cowrote "Empirical Software Engineering: As researchers investigate how software gets made, a new empire for empirical research opens up" in the latest American Scientist, in case you want a taste of his approach. We can now do metasurveys and overviews of existing research into software development, and the science says:

Pair programmers tend to produce code that is easier to understand, and they do so with higher morale. Their productivity may fall initially as the programmers adjust to the new work style, but productivity recovers and often surpasses its initial level as programmer teams acquire experience....

Doctor Ella Eulows (right) and laboratory assistant Sadie Carlin (left) testing antipneumoccus serum for potency, 1920, public domainLarge meta-analyses and further studies by Hannay and others conclude that a programmer’s personality is not a strong predictor of performance. The people who swear by their beliefs about personality and programmer success have now been given reason to assess their position critically, along with methodological support for doing so....

....the distinctions between the two worlds are often illusory. There are cathedrals in the open-source sphere and bazaars in the closed-source. Similar social and technical trends can be documented in both.... Schryen and Rich sorted the packages they studied within categories such as open- and closed-source, application type (operating system, web server, web browser and so on), and structured or loose organization. They found that security vulnerabilities were equally severe for both open- and closed-source systems, and they further found that patching behavior did not align with an open–versus-closed source divide. In fact, they were able to show that application type is a much better determinant of vulnerability and response to security issues, and that patching behavior is directed by organizational policy without any correlation to the organizational structure that produced the software.

fishery biologist, 1972, public domainI read about software engineering research while sitting at the bar, over lemon-lime-and-bitters and devilled eggs served with slices of jalapeño. I always love getting to watch people who are good at their jobs, and the craftsmen at Ward III have a particularly explicitly collaborative style with their customers. One of them, Michael J. Neff, blogs at Serious Eats about cocktails and tending bar. He writes thoughtfully about the use of sugar, free-pouring versus using jiggers to measure, why Californians like us find hurricanes so unsettling ("I tend to think natural disasters should be short, violent, and most of all, unannounced."), and the downside of cocktail nostalgia.

Much of the current cocktail trend is based on nostalgia, and it is difficult to say it, but many cocktails that we now call "forgotten classics" are forgotten for a reason. They have the shine of history, and we're told we are supposed to love them, but they're too sweet, they lack balance, and they kind of suck....

...none of us invented the cocktail. Whatever we create now is a collaboration between those who make spirits, those who make cocktails, and those who imbibe them. If we leave behind the drinker, we leave behind the only people who can tell us what works. None of us make cocktails in a vacuum.

No matter what field you're in, it can be hard to hear criticism. It can be hard to switch habits in response to new data, from your customer or from research. But that's what learning is. Disequilibrium -- surprises, failures, jokes, and disorientations -- will always happen. Taking that opportunity to move away from a local maximum towards a global maximum is up to me.

Filed under:

: Work And Being Realistic: Mumbai Wikimedia Hackathon 2011 This month I'll briefly be in Mumbai for a Wikimedia developers' meetup. Developers and translators will be working on mobile and offline access, localization, and general knowledge sharing about Wikimedia technologies. If you're interested in coming by, let me know.

Selected recent Wikimedia (work) stuff: Guillaume Paumier did important foundational work in collecting and integrating information for a MediaWiki architectural overview and history. I've already pointed newbies to it at least five times to explain something. And the first MediaWiki 1.18 beta release is out so people can download and test that. We're hiring for like a dozen technical positions. There's so much going on that if I go on I'll end up repeating our monthly reports.

Perhaps more interestingly, my current crusade is patch review. When new technical volunteers show up, perhaps trying to scratch their own itch or get started with an annoying little easy bug, they contribute patches in our Bugzilla. We're not reviewing and responding to them consistently and quickly enough; there are more than 260 patches awaiting a response, some dating back years and thus suffering bitrot. So, the workflow isn't working. I'm working on figuring out what's broken and how to fix it.

All my Wikimedia work and travel has kept me from my previous big open source commitment, GNOME. I've been saying to friends and GNOME teammates for some time now that I can't keep up, and am now unsubscribing from the GNOME Marketing and GNOME Journal team email lists in recognition of that fact. It hurts, but it's better not to pretend to commitments one can't keep. Fortunately, Emily (Rose? not sure of her last name) & Sriram Ramkrishna have done a great service in moving GNOME Journal to a modern publishing system at It looks like they'll take over running and editing it, which is lovely. Paul Cutler and I simply have not had the time to give this information channel the attention it deserves, so he and I asked for others to step in and take over, and I am glad to see Sri's, Emily's, Allan Day's, and others' energy pushing forward to keep the GNOME and FLOSS communities informed about GNOME happenings.

We are in this together. It's like the geek feminist saying goes:

Let's say that fighting sexism is like a chorus of people singing a continuous tone. If enough people sing, the tone will be continuous even though each of the singers will be stopping singing to take a breath every now and then. The way to change things is for more people to sing rather than for the same small group of people to try to sing louder and never breathe.

The demands of scaling up imply, somewhat recursively, that in my role coordinating and recruiting volunteers, I need to also recruit people who will coordinate and recruit volunteers. I'm working on it.

Filed under:

(6) : Everybody's Doing It: Some Hackathon Tips: Hackathon 2011 Berlin - 2ter Tag - TS (44)I'm helping arrange some developers' events at work. They're meant for open source software developers, testers, documenters, and other contributors to get together, talk, and collaborate. We often call them hackathons. I'm directly planning, with a colleague, the October 14-16 hackathon in New Orleans. But I'm also advising volunteers and people at partner organizations who want to put on technical events -- for example, a British contributor is planning a hackathon in Brighton, 19-20 November. The Wikimedia Foundation itself can only put on a few events a year, but there's plenty of room and demand for smaller regional meetups, so I'm enthusiastically encouraging volunteers who want to throw a hacking party.

People keep acting as though I'll have useful advice for them in hackathon planning, so here goes! I do not want to reinvent the wheel here, so I'm liberally linking to others' existing guides and HOWTOs.


Wikimedia Hackathon Berlin 2011 group photoMy colleague Siebrand Mazeland wrote some goals for an upcoming hackathon and I like them as an example. Note that this is for an event where we're expecting that most participants will be new to MediaWiki and to open source development in general:

First I'll talk about the social/content side of hackathons, and then some outreach/process stuff, and then the technical/logistics side.

People & Activities

Here's what I wrote while helping plan an upcoming hackathon, one of the first in its region:

Hackathon P1030931

Since I predict that at least half of the participants will be new to MediaWiki-related development, we'll want to seed the crowd with some more experienced developers (if possible, from the region). And we'll want to provide some direction and some pre-planned activities, especially for the first day (if we're assuming a two-day hackathon).

One of these activities should be the "how to start modding MediaWiki" lecture/workshop that we first led at Wikimania. A colleague and I will be cleaning up those notes in September to create a curriculum that a local developer could use to teach.

Other preplanned activities would include just enough structure to help inform and guide the energy of new, uncertain participants. For example, organizers should ask several local developers, ahead of time, to prepare sets of tasks that small groups could work on, such as "fix these ten bugs in Kiwix" or "add language support for (this language) to (tool)." It would be best if these developers could also give extremely short talks about their areas of interest (3-5 minutes each, no slides necessary). In the afternoon of the first day, and at the beginning of the second day, there would be a twenty-minute period of these "lightning talks" and then participants could decide what group to join.

Hackathon 2011 Berlin - 2ter Tag - TS (65) I am generally in favor of allowing some room for spontaneity, by asking participants on the first day what they're interested in working on, encouraging them to give ad hoc lightning talks during the short talks sessions, and by encouraging participants to lead sprints on topics of their interest. Technologists feel more inspired and creative if there's lots of support (people who are willing to teach and mentor) but also freedom to discover and concentrate on new interests.

It's tempting for organizers to say "let's concentrate on this! and this! and this!" at a hackathon. But you can't concentrate on localisation, and mobile, and accessibility, and HTTPS, and mass uploaders, and usability, and the article feedback tool, and and and. :-) If you really want some topic focus at the hackathon, choose maybe 2 concentrations a day, and target your outreach and publicity, saying that you especially welcome participation in those areas.

Some Things You'll Need for a successful developer outreach event:

Technical stuff & logistics

Hackathon 2011 Berlin - 2ter Tag - TS (75) I find that the Stumptown Syndicate's Event Planning Handbook section on logistics ably summarizes the logistical side of what's needed at a technical event.

Basically, once you have a venue, the next priority is provision for robust wireless (and, if possible, wired) internet, and provision for heavy electrical power usage.

You'll want to have some kind of documentation of your hackathon, to make it easier for people to collaborate (face-to-face and remotely), and to have a record for future reference. As we decided for the Berlin WMDE hackathon this year (thanks to Daniel Kinzler for distilling this hierarchy):

  1. textual documentation: essential
  2. live textual documentation (IRC, Etherpad): important
  3. photo documentation: important
  4. audio recording: important
  5. video recording: would be good
  6. audio streaming: would be good
  7. video streaming: nice to have

It's great to have two dedicated notetakers/facilitators typing into Etherpad for collborative notetaking, finding and answering questions on IRC and blogging, and walking around talking to people and asking them what they're working on and helping them collaborate more effectively.

Hackathon P1030929 And below I'll reproduce a note that Jon Davis, formerly of Wikimedia internal IT, wrote about audio recording and streaming (when planning for the Berlin WMDE developers' days):

The biggest problem is getting reasonably quality audio to a computer. The single biggest complaint I've had... was that it was hard to hear people. [You'll] need some reasonably quality microphones to capture with. If it is presentations, I recommend some sort of shotgun style mic. If it is a group talk, something omnidirectional. The trouble is twofold.

#1 - I couldn't find any USB compatible shotgun mics off hand. You can, in effect make one with the right parts [1], [2], but it's definitely not cheap.

#2 - The USB omni-directional that I found [3] isn't cheap, and I've no idea what the quality is.

So [you'd] need at least one mic setup (and probably computer) per area [you] are trying to record. It's not... "great", but it sure beats running a ton of cable, doing mixing and all sorts of much more pro level work. I have no idea what the budget is for that sort of thing, so it might not be a big deal...

There is probably far better advice out there regarding recording/streaming video and audio. I welcome links and experiences.

You'll also want to consider bathrooms, garbage needs, whiteboards and markers, and maybe childcare, and so on -- the sorts of things conference organizers need to consider, in general. A few guides with tips on what to consider:

And of course there is a lot of "how to run a conference" reference material available for your perusal, including ConRunner, which focuses on science fiction convention organizers but which has more generally applicable advice. And hey, they're running MediaWiki!

Questions, links, comments welcome in the comments.

Filed under:

: Intra- and Interpersonal Expectations In Open Source And the Tech Industry: That theme emerges in the three articles I've written for Geek Feminism this year.

  1. January: "On competence, confidence, pernicious socialization, recursion, and tricking yourself" (previously mentioned in Cogito, Ergo Sumana). I have to remind myself to take my own advice and take more risks -- if I succeed all the time, I'm not thinking big enough. Echoed in Sheryl Sandberg's Barnard commencement speech.
  2. July: "'Put up or shut up'." I wrote this to explain the double-edged sword of the do-ocratic norm, to describe how we sometimes use it to shut down uncomfortable conversations, and to remind us that the very people who need certain new policies, procedures and abstractions are least able and worst placed to implement them. There's a difference between "that's definitely an issue; could you file a bug?" and "stop talking about this unless you're prepared to implement it all by yourself."
  3. Also July: "Google, gossip, and gamification: comparing and contrasting technical learning styles" tells my tale of failure and return, then asks: how do you learn technical material and skills? I'm especially interested in hearing from women who now spend a lot of time in a technical domain, but whose first attempt at learning it went awry.

By the way, if there's something you wish I would write about, do let me know.

Filed under:

(1) : Kyriarchy & Mr. Rogers: In late June, Kjerstin Johnson interviewed me for Bitch Media (makers of Bitch Magazine) about Wikimedia, feminism in open source, and related topics. You can listen to the half-hour interview via download from the Internet Archive, or read the transcript (4800 words, 67KB .doc file).

So open source means that anybody can modify the code; closed source means that no one else other than the people who basically sold it to you can modify it, and therefore you are disempowered, and you are under someone else's control. And as Mr. Rogers once said, "I am against the idea of anybody being programmed by anybody else."

The actual quote is: "Very frankly, I am opposed to people being programmed by others." I'm pretty sure I first ran into it in Seth Schoen's email signature.

Filed under:

(1) : "Learn Tech Management" Essay/Notes: Final notes, including an audio recording and an edited & annotated transcript, for my standing-room-only talk "Learn Tech Management in 45 Minutes" from this year's Open Source Bridge.

Sumana (publicizing a different talk) at OSBridge 2011, photo by Reid Beels CC BY-NC-SA

And I wanna also tell you that I am gonna talk a little bit about kind of managing up and managing down, but really more of what I'm talking about is managing up, because I think a lot of us have had at least some experience of managing other people and helping them understand what to do, but managing up is where it gets all mysterious, and people wear suits, and they talk about terms we don't understand.

And I think of this as kind of harm reduction. This talk that I'm giving right now. It's a little bit of the gentle art of self defense. Because, you know, you might be an engineer who has to deal with management and fight for your project, or you might want to take leadership of your open source project, and you might want to write proposals for what people should do or why they should give you a grant. Or you might accidentally turn into a manager at your firm. It might be foisted upon you.

And so I hope that some of the stuff in this talk will take you from, like, 0th percentile up somewhere else, and give you a bunch of keywords that you can look up on Wikipedia, the world's free, open source encyclopedia.

Subheaders include "Why do projects fail?", "Evil list", "Suit-friendly presentations", "Lenses", and "Q&A about measuring intangibles".

Much thanks to Christie Koehler for getting me that audio, and to Mirabai Knight of StenoKnight CART Services for transcribing my talk. Thanks to Reid Beels for the CC BY-NC-SA photo.

Filed under:

(2) : Open Source Bridge 2011:

Open Source Bridge - June 21–24, 2011 - Portland, OR

I had a wonderful time at this year's Open Source Bridge conference. Last year at OSBridge, I presented "The Second Step: HOWTO encourage open source work at for-profits" and had a great time. So this year I spoke on technology management, with the fairly ambitious title "Learn Tech Management in 45 Minutes". Addie Beseda reported such a high turnout that people were standing in the hall outside the door listening to the talk, which blows my mind. Audio and polished notes coming soon; slides & nearly complete notes available now.

@brainwane (from Wikimedia) and @WardCunningham (inventor of wiki) talking at #osbridge 2011. #osb11 photo courtesy Josh Triplett Because we released MediaWiki 1.17.0 (after 11 months of development and review!) while I was in Portland, I also led an unconference session on "What's new in MediaWiki 1.17 and How You Can Help". People volunteered to help us with PostgreSQL support, testing, design ideas, bug triage, the parser, and more. And I got to talk about the new release with Ward Cunningham, who invented the wiki. That has got to be a Sumana career highlight.

I also performed some geeky stand-up comedy, and people liked that. So that's nice.

Sessions I attended:

  1. DNSSEC @ Mozilla -- way over my head, which is fine.
  2. A Dozen Databases in 45 Minutes -- I found this very useful in helping me understand, among other things, why one would privilege availability over consistency. Thanks to speaker Eric Redmond for some memorable metaphors.
  3. Drupal Distributions, an Open Source Product Model made me think about the danger of fragmenting sub-communities within a larger FLOSS community.
  4. The open source communities panel -- I did not pay enough attention to this, as I was finishing up work on my talk. I do remember some people disagreeing about qualitative versus quantitative release management decisions and about how to recruit and mentor new participants; sadly I don't have any useful recollections.
  5. Selena giving a totally different talkSelena Deckelmann led "How to Ask for Money", which I think many people will find useful. Some of their lessons: "Find a fundraising mentor," "Hire a graphic designer", "Your network is bigger than you think," "Ask again anyway," and "Do what you say you'll do. And if you don't, communicate why - now."
  6. Dawn Foster's fantastic "Online Community Metrics: Tips and Techniques for Measuring Participation" was -- to all the community managers in the room -- worth the price of admission on its own. Hit the slides (per her blog post) for great pointers to MeeGo's statistics, MLStats for mailing list analysis, irssistats for IRC analysis, and more. And I have some additional notes at the talk's OSB wiki page.
  7. The Birds of a Feather session for Google Summer of Code proved educational; students, alumni, mentors, projects' administrators, and Google's GSoC administrators discussed challenges and opportunities. I learned that GSoC organizational administrators can email Carol Smith at Google to request possible travel stipends for their GSoC students to attend conferences, and possibly to look at previous mentors' evaluations to decide whether to keep them another year. Also, FLOSS projects report great success with the tactic of requiring applicants to do small tasks to prove they're serious and to set up those students to succeed, and mentors and org admins did not seem to think that this would unfairly weight admissions towards students who were already going to go into open source anyway.
  8. 418 I am a teapot note from the Mozilla party"Snooze, the Totally RESTful Language": hilarious, because Markus Roberts led it. My dents from the session:
    • # In Markus Roberts's #osb11 talk "Snooze, the Totally RESTful Language". Leonard, you never told me REST was a meaningless acronym. BETRAYAL
    • # Demo fail. "Anyone here have a laptop?" "What, you want me to go to localhost *for* you?" #osb11
    • # "I think there's a market for this, especially if we convince people that there is one." ... "Are you incepting?" #osb11
    • # Markus is now just riffing on soaking up consumer surplus, Bitcoin, NoSQL, pig Latin, & the joy of boundaries. #osb11
  9. Elizabeth Naramore spoke on technical debt (slides). One item that really struck me is her experience that sometimes chipping away at little tech debts won't get you the momentum & buy-in you need. You need a big thought-provoking goal.
  10. "Inviting Contributors to Open Source Webdev through Virtualization" by Les Orchard told me that not just Dreamwidth, not just Wikimedia, but also Bugzilla and are trying this concept. Four makes a trend! I hope they all compare notes. I also learned of a tool to sanitize real data dumps, to get useful test databases that community developers can use.

In between, I saw new friends and old, talked up MediaWiki, told people about the zillion open positions for which Wikimedia Foundation is hiring, played Dance Dance Revolution, ate great food, and enjoyed the inimitable atmosphere of a great conference.

A few ego-stroking notes: Open Source Bridge's Melissa Chavez also interviewed me for an eight-minute video. And, with Asheesh Laroia and Igal Koshevoy, I was named one of three Open Source Citizens by the conference organizers. Thank you for the honor; I will wear my scarf with pride!

(Thanks to the Wikimedia Foundation for the plane flight, to the conference for letting me in free as a speaker, and to my friends Brendan and Kara for hosting me. Thanks to Reid Beels and John Parker for their photos, which are CC BY-NC-SA. Thanks also to Josh Triplett for his photo.)

Filed under:

: Learn Tech Management In Probably Fewer Than 45 Minutes: I've put up slides and pretty rough notes from the talk I gave yesterday at Open Source Bridge, Learn Tech Management in 45 Minutes. I quote Langdon Winner and then Marx & Engels, summarize the efficient markets hypothesis as "we're not stupid," and give a list of spin tactics you can use to get or keep budget for a project. Audio & nicer notes to come soon.

Filed under:

(1) : Portland and San Francisco Travel This Month: I'm speaking at Open Source Bridge - June 21–24, 2011 - Portland, ORI'm going to be in San Francisco next week for in-person collaboration with my Wikimedia colleagues. Then, June 19-25, I'm at the Open Source Bridge conference, presenting Learn Tech Management In 45 Minutes.

It took me two years to get a master's in tech management. I save you $40K and give you the short version.

Managing innovation, intellectual property and employment law, corporate finance, building a business plan — my master’s degree in technology management gave me some grounding in a bunch of suit stuff. I’ll teach you a little of each of these, plus insights from my management experience and fish-out-of-water anecdotes. Aspiring executives welcome; ties optional.

It would be lovely to have time to hang out with acquaintances and friends in either location; contact me!

Filed under:

(5) : New Job, New Email Address: WMF logo As of this month, I'm a full-time contractor for the Wikimedia Foundation, serving as Volunteer Development Coordinator. My boss at WMF, Rob Lanphier, has just posted a welcome note that makes me sound all fancy.

In case you were wondering about my other clients from earlier this year: my paid work on GNOME Marketing, for the launch of GNOME 3.0, has ended, and I've also ended my work as fundraising coordinator for (passing it on to someone who has more time and relevant experience).

It might be disorienting to only have one job! I shall probably get used to it.

Filed under:

(1) : PICC 2011: My performance at the Professional IT Community Conference went all right. Consistent light laughter, some long belly laughs and several bits of applause. Sheeri Cabral and Tom Limoncelli really hit it out of the park on Slideshow Karaoke (best practices). Thanks to The League of Professional System Administrators for inviting me, and especially to Matt Simmons and William Bilancio for organizing my attendance and appearance.

A few things I recommended at PICC:

Filed under:

: GSoC, GSoC, Who's There?: As the organizational administrator for MediaWiki (thanks to my job for the Wikimedia Foundation), I am pleased to announce our Google Summer of Code students for 2011.

Also delight-inducing: the number of rejected applicants who hope to contribute to MediaWiki as volunteers. I'm trying to get them involved in their local Wikimedia chapters as well.

Filed under:

(18) : Do You Have 90 Minutes To Help GNOME?: I'm seeking volunteers for a fairly low-effort GNOME Journal task. I need about ten. You don't need any special knowledge about GNOME, just access to email and about 60-90 minutes of free time over the next two weeks. Let me know if you're interested!

Filed under:

: Geeky Standup Comedy as Value-Add: So, about that standup I'm doing this month. Have you perhaps further pondered, "It would be awesome if Sumana performed at a tech conference where I could also network with the IT community of New York and New Jersey, and attend training programs for way cheaper than I could get elsewhere"?

Your wait is nearly over. I will be the evening keynote speaker at PICC, the Professional IT Community Conference, on Friday, April 29th, in New Brunswick, New Jersey. PICC is a nonprofit production of LOPSA, the League of Professional System Administrators. Other (serious) speakers will include Tom Limoncelli, Sheeri K. Cabral, and the sysadmins from StackExchange. Python, Nagios, security, time management, Hudson, IPv6, all sorts of useful stuff.

PICC '11

The student rate is under a hundred bucks. Today is the last day to register at the early rate -- check it out!

(So yeah, all those other performances this month will be to prep for the PICC keynote. Please attend and help me improve it!)

Filed under:

: GNOME Contractor Status Update: Launch Week & Next Steps: (Also posted to marketing-list.)

My last email, on April 1st, mentioned that "my main TODOs today, this weekend, and early next week are to follow up on press contacts, the eReleases blast, and GNOME Journal." So I did that; that day, I got the eReleases press release out, and it went to more than a thousand publications. And then here's a list of what I did last week on GNOME:

Undone: I didn't put tasks in Bugzilla because they were moving too fast and I was in San Francisco, many timezones away from Allan in Bangalore, and couldn't coordinate effectively. Lesson for next time: do it early if we're going to do it at all. Similarly for setting up interviews with key GNOME developers; I dropped the ball there.

Now that we've launched, I talked with Allan about how to best use the rest of our contracts (we're booked to work on GNOME till the end of April). We think our priorities for the rest of April are:

(a) reach out to not-so-news-driven (more in-depth-reporting) journalists about aspects of the release that didn't get covered on launch day -- once we get some bites, prep developers who have volunteered, and get them interviewed

(b) write up lessons learned & ideas for next time

(c) infrastructure building & maintenance: update the wiki, consolidate audiovisual and textual resources, and otherwise help prep for future marketing, including press releases, talking points, etc. for the launches of GNOME 3 within distributions that will come out in the next weeks & months

So I'm going to make some progress on each of those this week. Specifically, I aim to reach out to two reporters, braindump a few lessons learned privately, and confer with Allan Day and Vincent Untz about resource consolidation. And I'm planning on pushing GNOME Journal's next issue forward, in collaboration with Paul Cutler, but that's not part of my contract since it's not GNOME 3-specific. :-)

Filed under:

: GNOME 3 Edition of GNOME Journal Published: I just pushed the button(s) to put out a new edition of GNOME Journal! This one focuses on the launch of the 3.0 version of your favorite desktop environment (assuming your favorite is GNOME). You can read these now at

We publish all our articles under the Creative Commons Attribution-ShareAlike 3.0 license. Please feel free to translate, podcast, repost, etc.

Thanks to the authors, our interviewees, the GNOME sysadmin team, and my fellow editors! And thanks to the hundreds if not thousands of contributors who have put their energy into GNOME 3.

Filed under:

(3) : GNOME 3 Marketing: A Snapshot: The story of this week, for me and GNOME marketing, is primarily the story of a press release. I collected quotes, revised it in response to feedback on marketing-list, added press contacts to our CiviCRM installation and emailed the press release to them (at least twenty contacts, with more to come). It should show up tomorrow on once the "we're delaying six months" April Fool's press release runs its course. We're now getting responses from interested journalists and I'll be answering their questions and helping them set up interviews with some key developers.

Also, I heard a success story from another open source marketer about ereleases, so I plan on editing the press release down to 500 words and paying $200 (the nonprofit rate) for their press release publicity service this afternoon.

By the way, in a previous status report I mentioned looking into Collabtive. It's terrible and I won't make us use it. For tasks involving responding to press contacts, we are using CiviCRM. I will be checking with Allan after the hackfest to see whether the remaining tasks would benefit from being placed in Bugzilla; I had aimed to do that before I fell ill.

This week we also had the second User Day. I did not publicize it as far ahead of time as I wish I had, but we did get some participation and answer some users' questions. Thanks to all the hosts!

After a discussion with Sri and Diego, I added "Approaches That Work" to the GNOME 3.0 talking points. If you need to talk with a skeptic about GNOME 3, we're hoping you can get some ideas, tips, and answers to common skepticisms there.

I also did some nagging, editing, writing, and organizing around GNOME Journal's GNOME 3 issue, which we hope to put out this weekend.

So my main TODOs today, this weekend, and early next week are to follow up on press contacts, the ereleases blast, and GNOME Journal. Thanks to everyone in Bangalore who's at the hackfest and working on the release!

Filed under:

: Joel On Coal: Hey, my ex-boss Joel Spolsky -- who said last year that he'd quit blogging -- has started a new blog about coal mining!

The other crucial thing about having a schedule is that it forces you to decide what seams you are going to choose, and then it forces you to pick the least safe corridors and cut them rather than slipping into pillar-robbing (a.k.a. slope creep).

Update: April Fool's! Postmortem.

Filed under:

: MediaWiki Accepting Google Summer of Code Applications: Just posted on the Wikimedia tech blog: MediaWiki got accepted as a Google Summer of Code project, so we're looking for project ideas, mentors, and students. More details at the techblog post.

Filed under:

: Ada Initiative Survey: Take the Ada Initiative Census

I just took the five-minute survey on women in open tech & culture (a really inclusive definition). The Ada Initiative is surveying people of any gender in "a wide range of activities and communities based around free/open licenses, and other forms of open, decentralised, and grassroots participation in technology and related fields." If you're reading this and you're not related to me, you should probably go take it. It really does take less than five minutes, and this data is crucial so we can gauge how well we're doing now and how far we'll go in the next few years.

Filed under:

: GNOME User Day This Thursday, 31 March:

CC BY-SA image of Bangalore by Sajith TS

As Allan put it: There are lots of enthusiastic GNOME users who have questions about the upcoming release, and there are plenty of people who are interested to hear about what GNOME 3 will be like. That's why I'm really pleased to be able to announce the first GNOME 3 User Day. This will be a great opportunity for people to get involved with the new release, to meet members of the GNOME project, and to find out what's in store in GNOME 3.

Well, that was for the first User Day. The next one is this Thursday, March 31st, in the #gnome channel of the GIMPNet IRC network. (Instructions for using Internet Relay Chat.) We'll be running three sessions over the course of the day (all times UTC):

GNOME logo Session 1 (07:00-08:00): Participate in the GNOME 3.0 hackfest
Hosts: Allan Day, Fred Peters, and Andre Klapper

Session 2 (15:00-16:00): The GNOME 3.0 platform
Hosts: Diego Escalante Urrelo and Luis Medinas

Session 3 (20:00-21:00): GNOME Shell Q & A
Hosts: Florian Mullner and Marina Zhurakhinskaya

I hope you'll join us! We'll be concentrating on those topics but feel free to drop in and ask about anything GNOME.

I used a photo from Sajith T S, CC BY-SA, of a park and fountains in Bangalore, because I hope we get a big crowd, because this User Day coincides with the Bangalore hackfest, and because information from friendly experts can be as welcome as water on a hot South Indian day.

Filed under:

(2) : A Slightly Disjointed (Due To A Five-Day Cold) Musing On Open Source, Fear, Motivation, And Witnessing: I was introducing C. to a set of QuestionCopyright friends and acquaintances, and they were joking about indoctrinating her, and she was curious to hear what free culture is all about. So she wondered why I reflexively suggested that the others wait a bit, tell her next time.

They did give C. the introductory spiel, and conversation was pleasant and edifying, and nothing terribly awkward ensued. She has developed a substantial interest of her own, now, in the theory and practice of free culture. But why did I have that reflex? I felt around for it and grasped something. It makes it harder, I said, once you know these things and care about them. Becoming a free culture/free software person is like becoming a vegan.

No, G. replied -- at least people know what vegans are.

We happy few.

Here I was, a fulltime free culture/free software consultant, feeling an unaccustomed reluctance to give someone else the sunglasses, to witness.

There are self-constraining ideologies like veganity or chastity that modern society at least theoretically understands, even if some cohorts scoff. Then there are the practices that always require an introduction. When I explain how I met Leonard, I often start with the thirty-second "what is open source" explanation, because it's all of a piece. But my "what is open source" intro focuses on pragmatism -- many eyes making bugs shallow -- rather than free software values.

DVD cover for film The Gnome-MobileI think I'm a moderate sort of open source gal, an ovo-lacto vegetarian. There's an iBook running Mac OS tucked off in a drawer, and all these Linux boxen in our house surely have nonfree binaries driving bits of hardware. No Facebook but I surely use many cloud services that violate the Franklin Street Statement. I hang out with copyright abolitionists, Debian users, and other free culture/free software folks who make me feel namby-pamby. And then I go to dinner with someone who makes me feel like a Jain. Or I find myself saying, as I said a week ago, that developing on a closed platform is like trying to fall in love with someone who won't talk to you.

Our love is part of what energizes us, moves us to act. In FLOSS, volunteers do things for two basic reasons: either because we enjoy doing them for their own sake, or because the task needs doing and we want to do our bit. We see some goal the task will help us reach, or fear an outcome the task will help us prevent. [By the way, it's useful to have experienced that, because it's useful to assume those two as the means of persuasion whether my colleague's paid or not. As a leader, I should either set up tasks people will genuinely enjoy (and get the scutwork out of the way), or help my colleagues see a straight line from the task to a glorious future. Show them how what we're doing leads to something they want. This is my pet theory of How To Lead Knowledge Workers and your mileage may vary.] And -- as a zillion social scientists will tell you -- even if we momentarily burn out on caring about a goal for its own sake, we don't want to let the team down. We don't want to let our buddies down.

As we were talking about GNOME marketing, Andreas once asked me what I found special, what personally spoke to me about GNOME. I rambled: object code is compiled from source code, but the source code is compiled, too -- compiled from people, from time, from love. Every time I look at my desktop, every feature and every bug comes from someone, someone with a name and a face, and sometimes I can even remember. Hey, I remember when she added that feature to Empathy. Oh, right, I know he's working on that bug. It's like all of Planet GNOME is helping me out, every day. It's like my whole community's right there, on my desktop, every time I open the laptop lid.

I don't want to keep my friends blissfully ignorant of this. Is there a more loving human impulse than the joy of sharing? I'm sorry, C. I'm sorry I was afraid of making your life harder. I remembered the local minimum and forgot the greater maxima awaiting you. Why keep us a "happy few" when we can be an ecstatic many? And yes, it's harder, to learn our principles and try to walk this path alone -- but the whole point of our principles is that our multitude, our diversity, our union, our communion is far richer and more sustaining than individual hoarding ever could be.

GNOME heart, thanks to Jeff Waugh
Filed under:

: New Edition Of/Nueva Edición de GNOME Journal: In this special edition of GNOME Journal, GNOME HISPANO's Juanjo Marin arranged for us to get five great stories in both English and Spanish. You can read these now at

The GNOME Journal features original content and commentary for and by the GNOME community. All articles are published under the Creative Commons Attribution-ShareAlike 3.0 license. Please feel free to translate, podcast, repost, etc.

Thanks to Juanjo, the authors, Diana Katherine Horqque, Will Kahn-Greene, Sriram Ramkrishna, and Paul Cutler for their work on this issue!

Issue 23 will come out around April 3 and focus on the release of GNOME 3.

Filed under:

(2) : Writing, Delegating, Researching: Marketing GNOME 3: Allan and I discussed some near-term priorities today in #marketing, so I'll document them here (and on the marketing list).

panorama shot of the Zaragoza hackfest room by Jason D. Clinton Allan this week is concentrating on release notes. He feels he has a good handle on what to write for the user side, but would like more input on what's changed for developers, so he wants advice/contacts on how to get that. I've suggested he do a session in #gtk+ or some other popular IRC channel and crowdsource some rough bullet points. He's also working on the Porting Guide -- as of today, he's working with Shaun McCance and the docs team. (This is part of our marketing to distributions.) We're hoping to coordinate with the docs team on this during their May hackfest.

He's already blogged/emailed what he's done so I won't rehash.

Sumana: Between my last note and now, I chased distribution marketing, clarified the role of the release roadmap, started a press release, got a CiviCRM account and started accumulating press contacts, chased video from launch parties and restarted the conversation about GNOME 3 videos, communicated & thought with Brian and Allan about promoting FLOSS and not promoting unfree software, reached out to potential volunteers (including on foundation-list), and recruited and edited articles for GNOME Journal's Issue 23 (GNOME 3.0 issue). And then today Allan and I hashed out some priorities in #marketing.

Sumana next to the crossed-off TODO items from the Zaragoza marketing hackfest, photo by Paul Cutler This week, to balance Allan's focus on two big things, I intend on doing a lot of smaller things.

  1. Get into CiviCRM and input our press contacts, start seeking the ones we want but don't have (Ars Technica, Wired, TechCrunch, O'Reilly online) in collaboration with Zonker
  2. Continue drafting 2 press releases, 1 for a Linux-specific crowd (like LWN) and one for a more general tech crowd (like Wired)
  3. Try out the GNOME install of Collabtive and see if Allan and I should switch our task management to that, or to Bugzilla (trying to track tasks in live.gnome wiki tables is not my idea of pleasant)
  4. With a little input from Allan, start setting up another GNOME User Day for late March
  5. Ask Licio to chase marketing localization
  6. Continue recruiting and editing GNOME Journal's GNOME 3 edition
  7. Reach out to docs team and other potential volunteers
  8. If I have time, chase videos/screencasts
  9. If I have time, some wiki cleanup
This is a lot and so it might change if more pressing matters come up, but I think it's a good place to start. Thanks again, GNOME community, for the opportunity to work on this!

(photos from last year's marketing hackfest in Zaragoza, Spain)

Filed under:

(1) : Yahoo! Labs Research Presentations, February 2011: Part I: This year, Columbia WICS let me come to another Yahoo! Labs research presentation/lunch (last year's notes). Thanks for the invite, Elizabeth Kierstead. My writeup begins here!

Ken Schmidt of Academic Relations started off by talking about all those other industry research labs and their SAD DECLINE. Bell/Lucent/Alcatel, AT&T Labs -- he'd seen them wither into irrelevance. (Despite that awesome Bell Labs Innovation song.) But Yahoo! Labs, started in 2005, is evidently hella relevant and vibrant. [Update: see comment below for clarification.]

Schmidt discussed the various groups within the labs, including Advertising Sciences or "AdLabs," which seems new. As he put it, there's a disconnect between the number of dollars spent on ads and how much time people spend clicking on them. (*cough* social media *cough*)

Columbia WICS women at Yahoo!, February 2011 The recruiting bit: you can pick which lab location to work in. They have a research lab in Haifa! And Schmidt assured us that Yahoo is woman-friendly, led by CEO Carol Bartz and featuring 500+ women in Yahoo's women's group. Mostly the same spiel as last year, including Schmidt's reminder of the Key Scientific Challenges program that gives grad students money, secret datasets, and collaboration.

I have the phrase "'billions & billions' of pageviews, etc." in my notes here and assume it's because Schmidt was pointing out how much data Yahoo! folks get to work with, and what a huge impact they make.

Then: student intros! There were about ten of us there, mostly grad students. Their interests ranged through social networks, data mining, spoken and natural language processing, privacy & security, compilers for heterogeneous architectures, and economics.

First presentation: Elad Yom-Tov's and Fernando Diaz's "Out of sight, not out of mind: On the effect of social and physical detachment on information need". Let's take three example events: the San Bruno gas pipeline explosion, the New York City tornado, and the Alaska elections. People might be interested in searching for information about them because they live nearby, or because they have friends who do. So you measure physical and social attachment/detachment: physical distance and number of local friends.

What data did they use? The query log: userID, time, date, text of query, results, what they clicked (with term-matching, inclusion + exclusion). The location data: the ZIP code the user provided during initial registration. I'm skeptical of that but the researchers say it's fairly reliable, although "more than we [would] expect live in Beverly Hills." And the social network: the number of instant messaging contacts you have who live in the relevant location.

There's a strong correlation with physical detachment, an exponential fit. As for the social network: the more local friends you have, the more likely you are to ask Yahoo! about the event. Beyond 5 friends, the data is noisy, and we don't have a lot of data there, but overall it's a very nice fit, strongest with the San Bruno data. And if you're local, you have more local friends, but that isn't strong enough to explain what we see.

Thomas Hawk, Burned Car in Driveway, San Bruno Gas Line Explosion, 2010 In terms of time: attention span is limited. People's attention wanes after about three days.

The researchers compared people's queries along the social and physical distance axes, looking for unusual phrases -- phrases that trended up around the dates of the incidents. If searchers are physically close to the incident, whether their friends live there or not, they use the same words. Like, for the NYC tornado: queens, picture, storm, city, nyc. If they're physically far away but have friends in New York, they use terms like brooklyn. [Also mentioned: new(s) and york, but that might be a stemming fail.] But a term that people both physically and socially detached from New York City searched for: statue of liberty. Is that grand lady all right after the tornado? America wants to know! (Yes.)

(The presenter then spoke about clustering queries by words, since different words signify different informational needs, but this bit had pretty bad graphs and I didn't understand.)

So Yahoo! wants to learn to identify relevant querier. "Pacific Gas & Electric" is a legitimate query that people search for on any given day, but it would be possible to programmatically tell that it has a lift due to current news. So Yahoo! wants to act relevantly. In the PG&E example: most days, the search result is and should be the PG&E homepage, but on that day, a top result or sidebar should be a news item about the explosion. A more abstract way of saying this: "learn a retrieval mode for each detachment level." Using social knowledge gets ranking results that are better than just geotargeting -- the difference is statistically significant -- and better even than combining a person's geographic and social detachment levels. "There's a problem with 'both,' probably because of the way we trained our models."

Previous studies suggested that the further a news source is from where something is happening, less likely the news source is to report the event. And Yom-Tov & Diaz's work bore this out. News as a function of distance drops exponentially, as do tweets. Interestingly, when you look at the temporal spike orders (which came first?) on Twitter mentions/searches, the Yahoo! query log, and mainstream news coverage, you see different spike orders for the different events. Sorry, I don't have more details, but I bet the researchers do.

One interesting side effect: we can look at people's queries and infer their location (although you can of course usually also do that with IP addresses). You can even track a hurricane by tracking where the queriers are over time.

These take a while to write up, so I'll save David Pennock's microecon research overview, Sebastien Lahaie's "Advertiser Preference Modeling in Sponsored Search," and Sharad Goel's confidence calibration project for later posts. [Edited 9 June 2014 to say: no, sorry, I will not be adding Part II.]

Filed under:

(5) : Wikimedia: Now that my new bosses have told the world: yes, I'm also now consulting for the Wikimedia Foundation, the nonprofit that supports Wikipedia and other free knowledge initiatives. To grossly simplify, I'm coordinating software development (mostly MediaWiki improvement) that isn't by WMF staffers, primarily concentrating on the upcoming Berlin hackathon and this year's Google Summer of Code participation.

Thank you, nostalgia: in December, I was looking up my old high school classmate Christine Moellenberndt, and discovered she was a new hire, then looked at the current job openings, and applied.

I told my mom about it and it went something like:

"Mom, I'm working for the nonprofit that does Wikipedia! ... No, not them, they're different. Wikipedia is a big free encyclopedia that's online for anyone to use. Wikileaks is a ... well, they're a bunch of people who like to get and publicize secrets -- anyway, that's not us."

And no, this holiday season my photogenic face will not be on banner ads entreating you to give. As far as I know.

Filed under:

(1) : Careering: Since I last mentioned my career, I have turned into a consultant. I have a few gigs; let me tell you about two of my clients. is a nonprofit that aims "to educate the public about the history of copyright, and to promote methods of distribution that do not depend on restricting people from making copies." I'm QCO's Fundraising Coordinator, meaning that I write and coordinate grant proposals. I also write a tiny bit for the QCO website. Case in point: "Three glimpses: Transformative work, public domain music, and ethics".

The GNOME Foundation, the nonprofit that supports the GNOME desktop, has hired me as one of two contractors to manage marketing for the launch of GNOME 3.0. Allan Day and I will be (to oversimplify) ensuring that Linux users know what's new in this release and why it's awesome.

More on those and my other work when I can!

Filed under:

(1) : Recruiting: As you might have seen from my microblogging, I seem to know a lot of firms that are hiring. In short: I know people who are looking for project managers, UX designers, backend developers, undergrads who code, playtesters, kernel & mobile hackers, so if you know me at all, feel free to contact me to ask for an introduction.

Wikimedia, the foundation that supports Wikipedia ("No, Mom, not Wikileaks, that's different"), is looking for lots of engineers (deadline in 2 days) and fundraisers/researchers/analysts/more. The Volunteer Development Coordinator role also has a 11 February application deadline: attention, open source community managers!

Get paid to hack Linux mobile and save vendors & developers from constantly reinventing the wheel at Linaro. They especially need kernel and Android hackers and technical project and product managers.

OpenPlans, the New York City nonprofit that uses technology to make cities better, has decadent offices and benefits. Oh, and they're looking for a web designer, two engineers, and a fundraising manager.

Socialbomb, the Brooklyn startup that creates stylish experiences connecting Blu-Ray and mobile devices to Facebook & Twitter, is looking to fill several roles, including development.

I'll be administering some Google Summer of Code work this year, so I'd like to recruit bright university students to consider applying. It's never too early to start thinking about summer internships! And don't worry too hard about qualifications: "Do you have some programming experience at the university level? Then, yes, you are good enough! No, you don't need to be a Computer Science or IT major."

And I know at least one more project that's looking for a part-time playtester and a part-time project manager, so let me know if you're interested.

Filed under:

(1) : Is Our Sumanas Learning?: Yesterday + today:

Project Hamster screenshot Project Hamster is a nice timetracking app, better for my purposes than is gTimelog.

The magic code to add to an HTML page to make RSS autodiscovery work: <link rel="alternate" type="application/rss+xml" title="RSS Feed" href="/rss.xml">

What domain name to use, and thus how to construct an email address for email-to-SMS on my phone.

Where the downloadable gzipped archives link is on mailman archive pages (example). On the right, right under my nose; no need to cast about and start constructing a wget command.

Filed under:

(3) : When Am I Ever Going To Have To Use This?: Yesterday, while negotiating with potential clients, I used:

All that school comes in handy sometimes!

Filed under:

(2) : What's Obsolete & What's Still True?:

In India the number of institutions and organizations installing computers is growing at a rapid rate. This is a welcome sign. More and more of our workers in factories and offices will now turn the monotonous and routine jobs over to the computer, and thus will be cured of the nervous tension which they suffer unconsciously day in and day out. These workers, thus rendered healthy, will be an asset to the country and will devote themselves to more challenging tasks which need the ingenuity of a human brain.

From Essentials of Computer Programming in FORTRAN IV, Nripendra Nath Biswas (Indian Institute of Science), Radiant Books, Bangalore, India, 1975. Page vii; second paragraph of the preface.

My mother knew FORTRAN; she used it, she tells me, in a night job doing data entry at a nuclear power plant. Her FORTRAN teacher said she was awesome and encouraged her to go into programming fulltime; she declined because she didn't want full-time daytime work, or already had a day job. I wonder how my life would be different if I'd grown up with punchcards.

...Where do we write these statements and how does the computer read them? It is quite obvious that writing these statements on a piece of paper and holding it in front of the computer will not solve the problem. (At least not right now. The computers of future generations will surely acquire this capability.)... -p. 33

Considerable research is under progress to improve the capability of a programming language, so that it can itself correct certain types of errors. Even then it is obvious that a programmer will need a more rigorous knowledge of the language to write a computer program than the knowledge of French that an English speaking tourist needs when shopping in Paris... p. 52

Je voudrais un silver bullet!

Filed under:

: A Turn From The Personal To The Professional: I'm seeking a new position as a project manager or open source community coordinator. From here I'd like to get into product management with a sideline in mentoring engineers in career development. Resume, LinkedIn, email, homepage. New York City preferred; will also consider Boston, San Francisco Bay Area/Silicon Valley, and the United Kingdom.

Filed under:

(3) : Anyone going to in Bangalore in a few days? I'm thinking of attending on December 15th, the day before I fly back to the USA. Perhaps we could hang out.

Filed under:

(8) : To Build A WiFire: Nandini advised me that video chat with her fiance makes it far more bearable to be away from him, so I decided to investigate the Google Chat videochat integration in Empathy so I could videochat with Leonard for free without having to install anything proprietary (read: Skype). It worked fine between my and Leonard's Ubuntu machines when we were in the same apartment in the States, but my Empathy froze up when I tried to initiate an audio or video chat from here in Mysore. That was just over wifi, though; it kinda worked when I plugged into an Ethernet cable. Kinda. (I hereby apologize to my former coworkers and the GNOME community for not actually making efforts at debugging this yet; I may poke at it soon.)

Over two days, my pal James A., a sysadmin who lives in Perth (Western Australia) and thus inhabits a time zone suddenly much more congenial to random conversation, spent at least 90 minutes on the other end of the notional line, helping me work out a few hitches and exchanging the most boring possible text and audio chat with me. "I can't hear you." "Oh, my mic was muted." That sort of thing, interrupted of course by talking about themes in Snow Crash and The Diamond Age.*

From the middle of that: "OK, now your face is just a bunch of blocky squares." "Yeah, that's a natural consequence of aging. I learned that from moisturizer ads. If you don't use Oil of Olay then your face gets all pixelated."

From the end of one troubleshooting session:

Sumana: Well I think we've all learned a valuable lesson today
Sumana: and that lesson is, never make a friend who does not live in your postal code
Sumana: and never leave said district
James: or take them with you
Sumana: Yes!
Sumana: Katamari them on up

It was around then that, while out on an errand, I thought I'd buy a longer CAT-5 (Ethernet) cable, since the one I had wasn't long enough to snake to my room from the router. So I walked to the computer-stuff shop a few blocks away.

"I need to buy an Ethernet cable. Do you sell them?"


We clarified that we were talking about the same thing. I shoulda just said "CAT-5."

"What length do you want? One meter, five meters?"

"What do you have?"

"What length do you want?"

"Just tell me what you have. What's the longest cord you have?"

"We have all lengths, which do you want?"

I sighed, said I was bad with meters, and estimated I wanted about 30 meters' length. That's when he went into another room and got out the mega-spool of CAT-5 and the hand-held crimper.

Oh. If only I'd brought my crimper! I knew how to do this, once!

Rakesh spinning a coil of CAT-5 around his arm

Rakesh cut off some insulation, got the wires in order (asking me what I meant to do with the cable so as to check crossover vs. patch), cut off the extra wire length, pushed the wires into the connectors, and crimped them into place. Then he tested the cord with a handheld device and frowned, then cut off one of the ends and started again. After this had happened a few times, we commiserated about Rakesh's inadequate crimper, which wasn't forcing the wires all the way into the connector with a nice click. I ended up going home and coming back for it an hour later, after he'd switched crimpers. Cost: 365 rupees (50-rupee crimping fee plus 9 rupees a meter), or about USD8. Carrying a 35-meter coil of CAT-5, tied with a couple pieces of string, on my shoulder down a muddy Mysore lane made me feel an authentic part of the Indian tech scene.

What also made me feel authentic was coming home to discover that construction workers a block down had accidentally cut a line while digging and my household had neither landline phone nor broadband. The next day, Mom called The Guy She Knows at the telco, who came down and fixed it. I tried to talk with him in my incredibly broken Kannada plus Internet-related nouns. Sample, translated for sense into English: "Yes, cell phone, 3G, AirTel, it is. Right now, wifi do." He told me that WiMax has successfully launched in Kerala and is coming to Mysore, which led me to ask excitedly, "Mysore WiMax ya-wa-ge?" or "Mysore WiMax when?" which sounds like I'm some sort of Wired-reading Conan the Barbarian. About 15 days from now, apparently.

His colleague didn't speak as much English, so when I mentioned that I lived in New York City, this got reiterated/translated as: "She lives in America. New York City. A very big city. There was a bomb. [hands sweep across each other, like buildings falling down]"

"Yes, that's where I live," I agreed quietly.

connectors next to CAT-5, shorn of insulationI got to see a minuscule slice of that city yesterday, when I videochatted with Leonard.** (For now it's soundless video + a plain telephone call for audio; more troubleshooting is in our future.) A less sweatshoppy laptop, some open protocols and FLOSS software, a friend's help, a bespoke Ethernet cable, innumerable components and stories and wires and decisions forming the infrastructure of the digital world, all so I could pretend to be a crab clacking my claws at my husband. Nandini was right.

* I mentioned that Stephenson is obsessed with how to best arrange for institutions to keep going past any one member's death, and James pointed out Uncle Enzo's career and his disdain for the Young Mafia. Also, when James mentioned that WordPress is written in PHP, which is really itself a CMS, I called WordPress "an unstable sedan chair atop a drunken Godzilla," which I don't stand by, but which is funny anyway. WordPress is more stable since I last had to work with it and I shouldn't be so hard on it, especially since they folded the great WordPress MU back into trunk. I am curious about Melody, though.

** "Just so you know, since I introduced you to Beth and Pat and Lucian, I expect a commission." "Oh, okay. Some kind of friendship commission?" "A blue-ribbon commission." Plus me listing off a bunch of names and him adding one more. What do these people have in common? Randall Munroe, Vienna Teng, Jonathan Coulton, Ken Liu, Charles Stross, Darcy Burner, Seth Schoen, Vernor Vinge, Ellen Ullman, Joel Spolsky, Eric Sink, Ryan North, Neal Stephenson, Paul Graham, John O'Neill, Naomi Novik, Kristofer Straub, Leonard Richardson, and arguably Jerry McNerney.

Filed under:

(2) : Why I Haven't Replied To You: I haven't explicitly said this before, but: I'm spending a lot of my time taking care of my mother. Since my dad died this summer, she's needed a little looking-after. If I haven't responded to your message, that's why, and the situation will probably continue until early next year, at which point I hope to be a responsible member of the GNOME, geek feminist, and other communities again.

(I'm in New York City right now but plan on traveling a lot this fall to be with my mom.)

Filed under:

(7) : Two Tips On Convincing Managers & Executives To Invest In Your Technology Projects: From a years-old job-advice email to a friend. The sort of knowledge that Rachel Chalmers or Karl Fogel finds obvious but that some of us still haven't quite integrated into our day-to-day communications and long-term strategies:

You need to be able to express your suggestions to your boss in terms of financial incentives and losses.

A few things I've picked up during a recent class in "Technology in the Business Environment" (when I was doing the master's in tech management at Columbia):

I) Management focuses on the things that drive the organization (directly making money), and tends to ignore things that support the organization's drivers. If you're directly making money, lowering the cost of producing the product/service, increasing management's control, increasing product quality, increasing the knowledge available to an important decisonmaker, or improving customer service, you can describe your work as a driver. Can you find a way to describe your high-level TODOs in one of those ways?

II) Here's a model of management's priorities for technology investment. The higher up this list you can get, the more attention you can grab from management.

  1. Revenue. Guaranteeing a financial return. Not just cutting costs, but actually MAKING money from customers.
  2. Increasing scarce productivity. If the demand for a product exceeds the supply, then this is attractive. [1 and 2 indicate that the company is growing, and interested in the future. A good sign!]
  3. Cutting costs. More popular in a struggling company.
  4. Competitive advantage -- this means the company is already behind its competitors and has lost first-mover advantage.
  5. Tech for the sake of tech -- pizzazz and leadership.

So can you explain "creating system-monitoring scripts, streamlining processes, and installing and configuring new programs on the server" so that they're way up on that list?

Let's say a system-monitoring script would take your service from 95% uptime to 99.9% uptime. That's #2. Maybe one of the high-level tasks you do will make it possible for your company to serve twenty units instead of fifteen (#2) or even start a whole new line of products (#1). But "It's more elegant/technically correct" is #5.

I welcome comments, tips, examples, disagreement, and cake.

Filed under:

: Announcement: I've had a family emergency and will be intermittently away from the net for a few weeks. I will not be at GUADEC and I will not be part of DebConf.

Filed under:

: GNOME Journal: PHP-GTK, Shotwell, Nokia, & More: While I was gallivanting around to conferences, a new GNOME Journal came out, shepherded by new Editor-in-Chief Paul Cutler.

Enjoy! The Shotwell piece is useful (Shotwell now joins gthumb & F-Spot in my Apps menu) and the Gil interview is thought-provoking. I'll recuse myself from praising Paul's letter and my interview.
Filed under:

: The Second Step: HOWTO encourage open source work at for-profits: At the excellent Open Source Bridge conference earlier this month, people seemed to enjoy my talk. The one-liner:

Even at pro-FLOSS businesses, logistical obstacles and incentive problems get in the way of giving back. I’ll show you how to fix that.

My session notes are now available. If you were there, please feel free to clarify them and add your notes or links to your notes elsewhere.

The very short version: a company does not upstream its patches, even though it should for long-term practical reasons, because of problems in four general categories. The company might lack a FLOSS culture. There might be legal confusion about what employees are allowed to do, and how to get permission. The project management workflow and timelines might not allow time for proper engineering. And the external project might have a terrible UI for new contributors.

Once you abstract these categories away from the specific problem of accidentally hoarded code rotting away, you see that they also apply to other problems of the type "I really know I should be doing foo but haven't gotten around to it."

I also added notes from my lightning talk on Thoughtcrime Experiments, in which I inadvertently invented a new social media marketing technique.

Filed under:

(1) : Snort, Chuckle: So I was watching a bunch of DJ Earworm mashups and saw this on my screen:

screenshot of YouTube page

What do you notice there? Perhaps this ad?

We love freedom of choice.  Why we dont support restrictions on creativity and innovation.

We love freedom of choice
Why we don't support restrictions on creativity and innovation.
Amusingly, if you actually go to, you get a Page Not Found. "Choice" is case-sensitive, you see.

As I knew before I clicked, this is a Flash-related Adobe vs. Apple salvo. Sorry, Adobe, I remember Dmitry Sklyarov.

Filed under:

: Zaragoza GNOME Marketing Hackfest, Day 3: Sumana next to the crossed-off TODO items from Thursday, photo by Paul CutlerOn Thursday, 6 May, the last day of the hackfest, we got so much done! (See Paul's photo). The "we" here came from three continents: Daniel Baeyens, Stormy Peters, Jason D. Clinton, Vincent Untz, Andreas Nilsson, Paul Cutler, Bharat Kapoor, Licio Fonseca, Ryan Singer and I came from both Americas and Europe for the GNOME Marketing hackfest. I'll quickly recount what we worked on that third day, though I know I'm missing some people and accomplishments.

On Thursday morning, Andreas, Paul, Licio, and Vincent worked on technical ideas for making it easier for people to demonstrate GNOME in live presentations; Paul will be writing more about that. Paul, Stormy, Ryan and I made plans to help GNOME community members learn to more effectively promote GNOME in their other technical communities (a simplification, sorry), and polished the wording of some key talking points for GNOME 3 (usability, accessibility, and apps). Thanks to the #gnome-hackers and #gnome denizens for telling us about apps and components users will love in GNOME 3, like gEdit collaborative text editing! Jason was laser-focused on video-making and giving other GNOME folks the information they need to make GNOME 3 demo videos.

Bharat spoke with me about brochure tactics (for example, every brochure should have a dedicated landing page on the website) and some branding issues (sometimes, multiple possible names are pretty much equally suitable, and the important thing is just to choose one and stick with it). He and I also discussed integrated marketing strategy. After all, marketing is a tool to get products or organizations things that they want -- such as sales, brand awareness, adoption, feedback, etc. -- towards a goal. Because this hackfest was pre-scoped as a GNOME 3 launch planning hackfest, we didn't rehash earlier GNOME discussions about goals. Still, at some point in the future (perhaps as part of the GNOME 3 post-launch review?), it might be nice to do some limited planning exercises to deepen our understanding of our goals and resources.

After lunch, we spoke about how to give Linux distributions the information they need about the innovations in GNOME 3, and the assistance they need to talk with their users about GNOME 3. We clarified and added to the GNOME 3.0 launch marketing schedule (feel free to grab one of those tasks).

panorama shot of the hackfest room by Jason D. Clinton As we wrapped up, we talked about continuing to work with the Zaragoza municipality and free software community; for example, since the area is doing so much work with accessibility, perhaps an a11y hackfest would be great for GNOME and for the local community. And we did a quick post-hackfest review of what we'd liked and what we'd like to improve next time. For example, using Gobby, the wiki, and IRC to document our discussions and work product as we went was good, but it would have been even better to use IRC more throughout (when possible) to let the larger world of GNOME and GNOME marketing know what we were up to, and to get their ideas.

Stormy finished the day by telling us that we'd gotten more done than she'd hoped, and that she was happy that people had stepped up to make things happen (once in a while she got to just sit back and watch!). She especially appreciated the Spanish people, such as Daniel Baeyens, Agustín Benito Bethencourt, and Ignacio Correas, who had taken so much time to work with us and show us the city. And Stormy thanked us for taking time away from work and home to come to Zaragoza.

That night we pub-hopped, and the next day I got on the train back to Madrid and flew back to the States. You'll see some more details pop up over the next week, on blogs or over on the wiki or the mailing list. I still have to write up some details from our notes. But for now I want to thank the hackfest's sponsors:

sponsored-by-gnome-foundation ASOLIF CESLA ZaragozaAyunt GobiernoDeAragonDep

Filed under:

(1) : GNOME & Conference Planning & Writing: I'm back in New York City. Big priorities this week include:

Filed under:

: GNOME Marketing Hackfest 2010, Day Two: On Wednesday morning, starting around 9:30, we broke into small groups to work intensively on video, GNOME Ambassadors, and the website. For example, Bharat, Vincent, and I started a business card template for GNOME Ambassadors, and Licio, Ryan, Stormy, and Bharat worked on the Ambassador brochures and website.

I had planned on starting some group discussion and knowledge sharing when the momentum lagged in the late morning. But it never did! So our first real break happened when Jose Felix Ontanon and Juan Jesús Ojeda Croissier joined their fellow Seville technologist Lorenzo Gil Sánchez to talk with us about accessibility work in the Andalusia region of Spain.

robot mural in ZaragozaWe did make a lot of progress in the morning: a GNOME 3 website mockup, a marketing brochure template, four video scripts, Ambassador website text, preparations for the 5-minute topic presentations, and other useful discussions and writing/communications.

After a lunch with them and with local officials and community, we heard a presentation from the city regarding their Digital City initiative. Some interesting facts:

I believe another hackfest participant will be linking to that presentation pretty soon. After that, Paul & Stormy met with the Spanish a11y mavens to talk about how GNOME can help the community & municipality get the publicity & feedback they need to make their FLOSS a11y & GNOME initiative a success, and talked with Vincent and the local municipality about similar possibilities. (Whew!) Jason tackled some screen-recording issues. Andreas designed an SMS fundraising card for Bharat's proposed SMS fundraising initiative, and began designing the brochures that Bharat, Vincent, & Ryan continued writing, and Licio is writing GNOME Ambassadors material. I turned the next 2 months of GNOME 3 launch TODOs to and people who want to grab ownership of or ask about a task should pipe up on IRC or the mailing list!

group dinner at BirostaSo our afternoon was pretty full. Even though the hackfest was supposed to end for the day at 7pm, people stuck around till the building closed 90 minutes later! I threw together some plans for tomorrow; we still need to have certain substantive discussions, and to make certain execution plans.

The Zaragoza and Aragon governments kindly picked up our lunch and a dinner at Birosta. The three vegetarians in the hackfest especially enjoyed a meal full of vegetables and free from anxiety.

I again want to thank all the organizations that are sponsoring this event: the Zaragoza Municipality, the Aragon Regional Government, the GNOME Foundation, the Technological Institute of Aragon, ASOLIF and CESLA. Also, the GNOME Foundation covered much of the cost of my travel here. So, thanks!

More reportage tomorrow...

Filed under:

: GNOME Marketing Hackfest (Zaragoza, Spain), Day One: Yesterday we officially started the GNOME Marketing hackfest, centering on planning the release of GNOME 3.0 on 29 September 2010. Paul Cutler started us off by talking about goals for the week. He wants us to blog about what we're doing, and to take care to recap action items and follow up after this hackfest to execute them well.

Stormy Peters noted that we have a great, diverse set of skillsets in the room. The last hackfest did a lot of groundwork and generated a lot of ideas and action items. This time, we want to get a lot of immediately useful things *made*.

Andreas and Sumana (Then we did introductions.)

Paul recapped the November marketing hackfest, which Jason Clinton and Stormy Peters blogged at the time.

I asked for a reminder of the GNOME mission: accessible, free, localized. We offer free desktop (technology) to everyone. We say "technology" these days because of mobile, cellphones, and so on, but mobile is not really what we'll talk about this week. For instance, the GNOME Shell team isn't targeting mobile handsets as a platform.

So, in that light: GNOME 3. What's in it?

(One issue to address is GNOME panel applets. Everyone Vincent has talked with uses about three applets (out of about 20 available ones), but everyone uses a different set of three. So we need to work with the community to find a way to bridge that experience gap for GNOME 3.0.)

So here are some notes towards our marketing message for GNOME 3:

(As we talked about highlighting GNOME apps, we reminded ourselves of long-term marketing ideas, less for GNOME 3.0 than for future marketing work: a cross-platform App Store that senses your OS and shows you free GNOME apps to download. Another: tie together About boxes on apps to Friends of GNOME. Make it easier for users to realize that they can give back via cash donations. Store what app inspired them to give cash, and feed that app's About box with specific users' names, once donations pass a certain amount.)

In a sense, our list of audiences (in order of priority) is:

  1. current users of GNOME 2.x
  2. GNOME developers
  3. the accessibility community
  4. distributions (such as OpenSUSE, Fedora, Ubuntu, and Mandriva)

And a home for our GNOME 3 marketing message: This will be a small, product-specific site that goes away (that is, redirects/moves to six months after the GNOME 3 launch (approximately). We're building the sitemap for it this week.

By the way, Paul and Vincent are going to coordinate on the improvement of the website; evidently there's a relaunch in the works! Plone is involved somehow.

Stormy and Andreas in ZaragozaStormy then led us through deciding what we'll do this week in the hackfest. HIGHEST priority:


And we roughly scheduled it as follows:

So Tuesday morning we worked on those talking points (soon to come to the wiki) and the launch roadmap (ditto).

After lunch, we finished our rough roadmap, then spoke about some various other topics before diving into website and Ambassador work. Bharat Kapoor suggested that we think about SMS fundraising at conferences, and about corporate sponsorship/involvement with Ambassadors.

As a group, we roughed out some ideas for what GNOME Ambassadors is (materials/collateral that anyone can use to evangelize GNOME) and for the website. One question re: the website: will it be a Plone site? There are some dependencies here regarding the existing website infrastructure and a delayed reboot; Ryan and I will talk about getting a project manager to do the CMS relaunch. In any case, we're going to go forward assuming that it's a Plone site that we can localize, and that the marketing team will own the responsibility for coding it and getting it up.

Then we broke into smaller groups to get more specific on the website and Ambassadors (to get wikified when we have time -- this week, I hope!) and developed some TODOs for the work session on Wednesday.

We also met local representatives who told us about the free software scene in Zaragoza and in Spain overall. We're so grateful to them for their hospitality and support!

(And throughout the day, we captured some other TODOs that we'll do after the hackfest...)

Filed under:

: Now I know in part; then I shall know fully, even as I am fully GNOME: I am in Zaragoza, Spain for the GNOME marketing hackfest. One thing that came up over dinner: People who have heard about GNOME 3 may have heard about GNOME Shell (a new UI that makes work less interrupt-y) and topic-based help. They might not have heard that the switch from gconf to dconf will significantly reduce applications' and the desktop's response time and OS login time.

Tomorrow the hackfest starts in earnest. Weird hotel mattress sleep, here I come! (It's 2:19am, regardless of NewsBruiser's attempts to make me look like I'm going to bed at a reasonable hour.)

Filed under:

(5) : Importing iCal .ics Files to N900 Calendar (Maemo 5): I have a laptop running Mac OS 10.4.11 and iCal 2.0.5 (ancient and proprietary, I know, that's why I just got the ZaReason Hoverboard running Ubuntu). I decided to move my calendaring over to my Nokia N900. iCal, select calendar in sidebar, File, Export, name it filename.ics, use Petrovich to send the file to the N900 over Bluetooth [Yay Petrovich! So great not to have to break out the USB cable], open the file upon receipt, Maemo Calendar automatically opens and imports, right?

Wrong. Only a few of my calendar items imported. I tried exporting a much smaller calendar in case it was choking on the number of items: nope. I tried diffing the file on my Mac and the file on the N900 in case it had gotten corrupted in transit: nope. And a hasty visual inspection didn't tell me the pattern of what had imported and what hadn't.

Evidently there are different versions of the .ics standard! vCalendar, iCalendar. Since I just wanted to move the content once and didn't need to set up a permanent sync solution, I started looking around for a simple clean-up importer. But then I ran into GPE Calendar, an alternative calendaring app that does properly handle iCal .ics files, before getting around to installing or running a standalone converter script. So I ended up doing this (thanks,

  1. Install GPE Calendar ("GPE PIM Suite calendar application") from the App Manager on the N900
  2. Within GPE Calendar, hit Import from the main menu and import the .ics file
  3. Verify that GPE Calendar handles the import perfectly (behind the scenes, it moves the .ics data into the GPE database)
  4. Open a Terminal and type

    gpe-calendar -e export-from-gpe.ics

  5. Move export-from-gpe.ics to MyDocs/tmp/
  6. Open File Manager and open tmp/filename.ics to get Maemo Calendar to import the file
  7. Verify that all events have imported by checking visually against iCal
  8. Uninstall GPE Calendar via the App Manager and bask in the pretty UI and integrated alarms of Maemo Calendar
I know, installing another calendar app just for the sake of its import and export seem like overkill. I am uncomfortably reminded of "Excel as a database". But it worked.
Filed under:

: Out the Door: Off to QuahogCon in Providence, Rhode Island. Say hi if you're there! I have some free time this afternoon and welcome sightseeing advice.

Filed under:

(3) : A Few Tech-ish-Related Observations: New Work City is a Manhattan coworking space/group that charges $25 for a desk for a day.

Floatleft: an international two-woman Drupal consulting firm that provides web development services to NGOs and nonprofits. Neat!

A similarly focused webdev firm is looking to hire.

KML or Keyhole Markup Language: an XML variant you use to mark up Google Earth or Google Maps.

Hierarchical Data Format: a file format that acts like a filesystem, for use with large & complicated datasets.

Unfortunately, when you do a Google search for [gnome source control] or [version control gnome], instead of, the first hit is the obsolete Subversion site (although it prominently calls itself OBSOLETE and directs you to git).

Filed under:

(1) : Yahoo! Labs Research Presentations, February 2010: Two months ago, Maritza Johnson organized a trip to the NYC Yahoo! research labs for Columbia's Women in Computer Science. As a Columbia alumna, I snuck in. (Something like fifteen or twenty high-powered CS undergrads and grad students attended. Always great to be in a lobby full of smart geeky women.) I heard about some pretty keen things there, so here's my writeup.

Ken Schmidt, director of academic relations, told us about some of Yahoo!'s academic relations work. For example, academics can get a bunch of useful datasets for research via the Webscope program. Yahoo! hosts university hackdays alongside its other worldwide hackdays. The Faculty Research Engagement program provides funding, datasets, and visits. The Key Scientific Challenges program gives grad students money, secret datasets, and collaboration. And Schmidt noted that there's an active Yahoo! Women in Tech network, and that they'll be at Grace Hopper this year.

At Yahoo! Labs, you choose your office location based on what's convenient to you, and then collaborate with other people in your discipline across offices. I didn't get a chance to see their videoconference meeting rooms but I get the sense they're great.

Following are some idiosyncratic notes on the presentations we got from Yahoo! Labs researchers. We also got to talk informally with Duncan Watts, who thinks a lot about experiments, social dynamics and behavior, and Sergei Vassilvitskii, who is taciturn.

Dan Reeves has spent four years at Yahoo! Labs and works on a mix of things. He talked about Predictalot, the Yahoo! prediction game for March Madness (the US college men's basketball tournament). Reeves, who doesn't know much about the NCAA, showed us some sample bets and kept getting dismayed that they were coming up at 100% or 0% potential, until actual basketball fans pointed out that his randomly chosen bet put up a rinky-dink conference against a heavy hitter. Domain knowledge is useful sometimes.

A few lessons: running quintillions of simulations (in the web browser, when the user selects a bet to make, I think) is hard, and thus programmers took "ridiculous shortcuts." The programmers made it possible to make "weird bets" (like, math involving the sum of the seeds that would make it to the Final Four), and not too many people have taken advantage of that, which is a little disappointing. And though the prediction market is very flexible, it doesn't give you more accuracy than you get already from crude, already-known variables.

But we already have an efficient and computation-assisted prediction market, and it's called gambling. Millions of dollars change hands every year as people bet on college basketball, and metrics for success and failure are clear, so I don't find it surprising that we're already very good at predicting outcomes from known variables. Perhaps a prediction market would lead to a greater increase in accuracy in a lesser-known sport.

That same slight disappointment came up in Sharad Goel's results. Goel thinks about homophily vs. influence, which seems intriguing to me, as does his "Anatomy of the Long Tail: Ordinary People with Extraordinary Tastes". To our group he spoke about what search can predict. That blog entry has all the details. Some key points:

You can use data from people's search queries to "predict the present." For example, people are all gaga about Google Flu Trends partly because it works around lags. GFT gives you results with a tiny lag, maybe a day; the CDC can't tell you results till it's been a week or two.

But can you use search to predict the future? And how well would that compare to alternative prediction methods? Well, you can check queries in the weeks leading up to a movie release and that'll give you pretty accurate predictions for its box office numbers, but "more mundane indicators, such as production budgets and reviewer ratings, perform equally well at forecasting sales." Specifically, there's already a Hollywood Stock Exchange. Again, where there's already a well-honed prediction market, you're not going to be able to swoop in and compete all Moneyball-style right off the bat...

Sihem Amer-Yahia researches social data management. She spoke with us about relevance algorithms for social surveys. You can construct implicit networks based on shared data preferences -- for example, rankings on delicious -- or shared behavior. (Yeah, remember, Yahoo! owns The Web Site Formerly Known As Over and over in these talks I was reminded that Yahoo! is making a lot of hay from their datasets: Flickr, delicious, Yahoo! Games, Yahoo! Sports (including fantasy sports), Yahoo! Mail....)

How alike are two people, based on what they tag or rank? Well, it's hard to systematically check this sort of thing via tags, because tags are sparse (whooo, folksonomy). Researchers looked at tags on Yahoo! Travel, like "family" or "LGBT." They parsed the tags and their usage to create "concepts" and to build "communities" around those concepts.

As I've known since Leonard created the Indie Rock Peter Principle, recommendation systems suffer from an overspecialization problem. As Amer-Yahia puts it, how can you incorporate diversity into the system's recommendations without hurting their relevance? Well, they have a lot of heuristics. One: use a greedy algorithm to pick the first K most-relevant results. Find which of those K results has the most similarity to that set. Then compare that most-similar result to the K+1th result. If the K+1th result is less similar, then swap it in. Continue to trade off diversity against relevance till you reach the lower acceptable bound of the relevance range (a range whose threshold you may have to discover empirically). It's a species of affirmative action.

Once you personalize recommendations (especially based on social networks), the indices you create and have to deal with get huge. I have a note here about "Storing like things together" and "Returning a composite of relevant items, validating with user's network" -- I assume those are partial solutions to the performance problems.

Another fun thing Amer-Yahia worked on: take Flickr photos and turn them into itineraries (longer paper at author Munmun De Choudhury's site). (Factoid: about 10% of Flickr photos come with automatic geotag stamping, and about 40% have semantic user-added tags that you can use to get some geographic data.) As the abstract says, "Our extensive user study on a 'crowd-sourcing' marketplace (Amazon Mechanical Turk), indicates that high quality itineraries can be automatically constructed from Flickr data, when compared against popular professionally generated bus tours." Oh yeah, the researchers love Mechanical Turk!

Amer-Yahia also spoke on homogeneity in structured datasets with strict ranking. Her demo used Yahoo! Personals as an example, which led to many subsidiary guffaws.

Basically, it's the diversity vs. relevance problem again. If you say you want to see college-educated white women aged 25-34 within 5 miles of New York City, you'll get a big dataset ordered by some characteristic. You can either rank by distance, or by age, or by level of education, but in any case you have like 100 nearly-identical results on the first several pages before you get to the first difference. It's hard to explore.

So instead we have subspace clustering, which sounds AWESOME. You cluster combinations of attributes in a rank-aware way, label them, and make sure that your resulting clusters of results have adequate quality, relevance, etc. Amer-Yahia explains this as dimension reduction to help users explore [results] more effectively.

John Langford works on machine learning. He pointed out a bunch of spots where Yahoo! sites use, or could benefit from, machine learning. He works on a "fast, scalable, useful learning algorithm" named Vorpal Wabbit. Langford demonstrated it and indeed it seemed plenty fast, although I haven't any baseline for comparison. Key phrases I noted include "linear predictor," "infrastructure helps it go & learn fast," and "plug in different, lossy-or-not algorithms?" and I assume interested folks can go check out the tutorial. A niche tool, but sounds invaluable if you're in his target market.

Jake Hofman showed us some more machine learning goodness. His tool (an implementation of vbmod, I think) scrapes the To: & CC: lines from your email to see who gets emailed together, and from that constructs a pretty graph showing the nodes & clusters in your social network. He tried it on a colleague's real mail, and indeed five distinct clusters sprang up. "That's my soccer buddies...that one's my in-laws...that's my college pals..." You can use this to have the Compose Mail interface auto-suggest recipients you might have left out.

I talked with Hofman a little after the presentations, whereupon he revealed that he hearts Beautiful Soup and Mechanize for screen-scraping login-protected or otherwise complicated websites. Evidently he got into Bayesian fun as a cell biologist getting software to automate the tedious task of classifying images from microscopes, slides, etc. Oh, there it is on his resume: "Applied machine learning and statistical inference techniques for high-throughput quantitative analysis of network and image data" and "Developed software platform to automate characterization of cell spreading and migration". Cool!

Siddharth Suri researches social networks and experiments and data mining. He presented his "Behavioral Study of Public Goods Games over Networks." He did an experiment on Mechanical Turk. Econ professors would challenge him on how representative of the population that sample is, to which he would rightly reply that they tend to experiment on university undergraduates, who aren't exactly hella representative either. Boo-yah!

Suri asks how we might get people to change or sustain socially beneficial behavior in a tragedy-of-the-commons situation. For example, how do we encourage energy conservation, discourage littering, and encourage donations to charity? I appreciate that it's a tough and important problem. However, he also said that the same question applies to online communities: how do we get people to upload photos to Flickr or write Facebook updates so everyone can enjoy them? He then investigated via a social dilemma game/experiment via Mechanical Turk, where strangers had the option to give or keep amounts of money, sometimes a "subject" was a plant who moved norms towards selfishness or altruism, etc., etc.

I find this question and approach a little bewildering. People write and share and upload online for many of the same reasons we knit scarves as gifts, host and go to birthday parties, and gossip and volunteer in the physical world. These are interpersonal, social actions that we do to bond or amuse ourselves or gain status within specific communities that have meaning to us. Experimenting on this phenomenon with strangers exchanging money on Mechanical Turk -- because that's where you can get experimental results -- seems weak.

Since this experiment was an initial pilot project, we suggested that future iterations allow the subjects to make friends with each other, or get pre-existing groups of subjects to join (e.g., have an experimental group composed of coworkers). Another attendee worried aloud that these measures might allow a "false sense of community" to arise and throw off the results. But who are we to call any sense of community false? And community is the answer to the social dilemma, anyway, isn't it?

Overall, a thought-provoking and enlightening way to spend a few hours. Thanks to Johnson and Schmidt for setting it up. I also thank Yahoo! Labs for the lunch, USB drives, pen gadgets, and fleece scarves. Let me know if I'm wrong about anything!

Filed under:

: GNOME Video Site, Mysterious Bugzilla Upgrade Patron, Mallard, Acire/Quickly, An Interview & A Goodbye: I'm an editor and the release coordinator for GNOME Journal, which just released its 19th issue.

This issue has six articles:

Paul, Jim, the authors and I put some hours into this and I think it's worth it. Check it out.

Filed under:

: Angie Martin: Last week, bloggers commemmorated the annual Ada Lovelace Day. It's a day to honor influential and inspirational women in technology and science. To quote one participant,

We are not Unicorns. We are everywhere. But our history is easily submerged, discounted and dismissed. Too easily forgotten.

Following the Women in Free Software blog aggregator today showcases how many women, living and dead, deserve this honor. Please excuse my belated post; this was hard to write.

Last year I listed some of my influences; now I'm realizing that every year I'll have the chance to celebrate at least one person in depth, so I'm going to speak about someone I deeply wish I'd gotten to know better.

mySociety core developer Angie Martin changed her name from Angie Ahl a few months into 2009, when she got married, and a few months before she died.

I'd met her on the Systers email list in October 2007, when she'd mentioned that she was up for a job with a UK org that created systems that helped facilitate government-public interaction and democracy in general. She doubted any Systers outside the UK would have heard of them, so of course I emailed her asking, TheyWorkForYou/mySociety? She got the job, and was "so chuffed": "I've been grinning for about 48 hours now," she told me, her morale sky-high that she'd impressed these people she respected so much. And she'd beat out an all-male field for the job:

Who says girls can't compete.

This was after she'd worked several years as one of a two-person web design firm, which was after hostmaster work at an ISP.

I mentioned that I knew Danny O'Brien, who was also in the UK digital-rights/participatory-democracy-tech scene. "...small world - I know him from years of reading need to know. I was jokingly going to wear my old battered NTK T-shirt to the interview... I should have done ;)", she replied. We talked a bit back and forth over the next few years. I'd hoped to meet her on a trip to London, but she lived in Cumbria (in the Lakes Districts), so we never met up.

She migrated the mySociety website to WordPress even while ill. She went on an org retreat, and got an Ada Lovelace Day shout-out from her colleagues.

Angie is mySociety through and through. A born perl hacker, never happier than knee deep in some grungy regular expressions, she's also gifted with an inate understanding of the possibilities of technology for democratic reform. At interview I asked her what change she'd like to see happen from the government side of our sector, and she replied that she thought the biggest possible win was to publish Bills in parliament in a proper format. You might have heard all this before, thanks to Free Our Bills, but Angie was commenting several months before we ever discussed the idea for the campaign with anyone else. She'd just looked at the world and the obvious problem had jumped out, clear as day.

She was eager to see Open Rights Group grow, and to see fair usage rights in the UK established properly. She loved the idea of Quinn's Symphonic Conundrum and wished it could be done. She loved Perl and jested that a bone scan that briefly turned her radioactive might give her superpowers.

In February 2009, Ahl learned that her cancer was terminal. She got married about a month later -- about a year ago. (Her widower, Tommy, is a photographer, and he loved to photograph her.)

Martin died of cancer in July 2009, having only begun the mySociety work she'd passionately wanted to do. Her partner, her colleagues, and friends and peers grieved their loss:

Angie was one of the true pioneers of the Lasso community.

Her contribution to the Lasso community was absolutely immense.

Angie and I often talked offlist about ways to move our programming ahead - about how to bring levels of functionality into reality that no one else was doing yet. Her level of understanding of the most abstract concepts, and how turn them into code was absolutely astounding.

She pioneered the error.lasso method, which so many people use today. She was also the first to figure out how to build search engine friendly URL's with Lasso. She contributed a ton of innovations, too many to list. Her contribution to the Lasso community is immeasurable.....

The fact that Angie was talented enough that she could have walked into a very high paying job with virtually any company in the world she wanted to work for (and could have named her own price salary wise), but chose to use her skills and her time to help a not for profit organisation like mySociety, speaks volumes about the immense depth of her character....

Given her habit of plain speaking, it is pointless to pretend that Angie was able to make the contribution to mySociety’s users or codebase that she wanted to. What she achieved in terms of difficult coding during recovery from chemotherapy was incredible, breathtaking – but she wanted to change the world. It now falls to the rest of us, and our supporters, to live up to the expectations she embodied...

What's that saying about the last full measure of devotion?

I hope this remembrance helps us appreciate all the tough, brilliant, geeky, dedicated women in our community, and work in memory of the ones who have left us, like Martin.

Filed under:

(2) : Web: About eleven years ago, I saw a link from Slashdot to a geek humor site called Segfault. I started reading it, then started reading the homepage of one of the editors. Leonard Richardson. He posted something new nearly every day, like a diary. (I didn't know the word "blog" in 1999.) He shared funny lines from his friends, his mom, his colleagues. I kept reading.

About ten years ago, I started reading Joel on Software. Just a few years previous I'd discovered Gerald Weinberg, specifically his The Psychology of Computer Programming, and loved it. So this Joel guy was talking about things I found interesting, and was introducing lenses, metaphors, models that immediately spoke to me. Fire And Motion. Ben & Jerry's vs. Amazon. The Law of Leaky Abstractions. Managers as the developer's abstraction layer (I later heard the synonym "windshield"). Smart and Gets Things Done. The iceberg problem in software development. Five Worlds. Architecture astronauts. I could go on.

Almost exactly nine years ago, I saw a funny line ("Those guys are gods of applied physics!") in an article on SFGate, decided that Leonard guy would appreciate it, and sent it to him. He and I started corresponding, and then hanging out. I went down to Bakersfield with him one weekend to help his mom move. Eventually we started dating.

About four years ago, I saw another pivotal blog post. I was living in San Francisco, in my third year working for Salon, and realizing that I'd like to go into management, and this Joel guy announced that his company was looking for me. Well, for someone who wanted to lead geeks, not necessarily a programmer. I saw that post, then woke up at 3am the next day, thinking, "I have to apply."

I applied, thinking I hadn't a chance in hell. Joel phone-screened me. I'd been told to prepare a short lesson ahead of time, on a topic of my choosing. So I came up with my stand-up comedy lesson plan, which I still use today. He asked whether, if accepted, I could move out to New York the next month. I hesitated a second or two, then said sure. They flew me out for an interview. I got an offer and said yes. Fog Creek paid handsomely to relocate my household. Leonard, who had left Collabnet to work on Ruby Cookbook, came with me. He'd never seen New York before we arrived in January of 2006.

Leonard and I were unhappy that we were moving so far from his mom. Frances had been fighting HIV for more than a decade, and had lived far longer than the doctors had ever predicted, but her health was still perceptibly declining. So I told him he should fly back once a month to see her. But he didn't get much of a chance to do that, because her health started getting much, much worse a few months after we moved. Leonard flew back and spent several weeks with her as she died. I took some time off to go be with her; later I discovered that Fog Creek had quietly, kindly given me those days for free, and not counted them against my paid time off.

Of all the job perks I ever got at Fog Creek -- relocation, half a Columbia Master's paid for, lunches, Broadway tickets, unlimited sickleave, Metrocard, a great library -- that one sticks with me most.

Oh man, this thing is getting long. Anyway. I learned a lot from Joel, before, during, and after my time at Fog Creek. I appreciate his decisiveness, his straightforwardness, his species of eloquence and encouragement, his financial generosity, his entrepreneurial spirit, and his insight. Sure, it wasn't all roses and sunshine, but he changed my life, mostly for the better.

A few days from now, Joel Spolsky will retire from active blogging, ten years after he started. Leonard and I are married, and still live in New York, and will for the next year at least. We still miss Frances terribly. Segfault's been gone for nine years. My Fog Creek salary subsidized Leonard's work on Ruby Cookbook, then RESTful Web Services. I have a master's degree in tech management and am looking for my next job in that field. Fog Creek was 6 or 7 people when I arrived, and now it's thirty or more. All those articles of Joel's are up on the web, ready for us to reread or brandish or rip to ribbons.

And so are my archives, and Leonard's, and Frances's.

It really is a web, isn't it.

Filed under:

: QuahogCon and Open Source Bridge: In the US style, the date is now 3/14, which makes it Pi Day. Happy Pi Day! (I'll have to remember to celebrate Mole Day on 23 October; I always forget, despite Mr. Marson's success in making me love chemistry.)

More calendrical news: I'm going to QuahogCon in Providence, Rhode Island, April 23rd-25th. They have infosecurity and DIY/maker tracks. I'm especially interested in a few talks:

but of course there's way more advanced stuff about SQL injection and WiFi vulnerabilities and bone-chilling madness, &c., &c. Let me know if you're going; I'm interested in splitting a hotel room with another woman. WILL YOU BE HER?

I've also nearly decided to go to Open Source Bridge in Portland, Oregon, at the beginning of June (right after WisCon, which may be a bad idea). I've submitted a proposal for one talk ("The Second Step: HOWTO encourage open source work at for-profits"), and plan on submitting one or two more.

Filed under:

(2) : Another Change: I'm no longer working with Collabora Ltd.

In the first several months after I joined Collabora in April 2009, I served as lead project manager, got the new website up, and started putting some new project management processes into place, especially in research and development. Then I shifted to personnel management, and created and began implementing a performance assessment system. All the while I gardened the wiki, aggregated and edited weekly internal reports to keep the company on the same page, blogged about our work, and generally gave people the information and the nagging they needed to make informed decisions. (In retrospect, I played facilitator, historian, and journalist a lot, plus mentor to 50+ Collaborans.)

Collabora's a different place than it was ten months ago; I helped move them from a startup to an enterprise footing. Management structures change as needs and capabilities become apparent, so the directors and new hires (including the awesome Martin Barrett) will carry this work forward, and I offer them my best wishes. I'm happy to talk more in detail about what I did at Collabora, especially if you're interested in what I can do for your organization.

In the near future, I'm taking some time to relax and take care of existing obligations before I incur new ones. Then, starting in late February or early March, I'll be volunteering fulltime on some open source/free culture projects for several months. I haven't yet decided which ones, or in what capacity, so feel free to recruit me.

Filed under:

: Change of Plans: I'm not going to FOSDEMImage nicked from Leo Antunes. (I thought about creating some sort of Belgian-waffle-with-a-NO-sign-on-it but this services.)

I'm not going to FOSDEM this year; change of plans. Perhaps next year.

Filed under:

: Tacky, Metacity, Encryption, tp-qt4, and Maemo: A few things Collabora folks have been working on recently (along with the constant stream of Telepathy-related releases):

Daf Harries released tacky, a simple python-based paste web app. Basically it's like a simpler version of pastebin, and you can install it on a private server in case you're talking about something confidential in private chat/IRC.

Thomas Thurman is looking for new contributors to mentor to help with Metacity (a window manager).

Cosimo Cecchi posted his TODO list for "a Telepathy implementation of the XTLS protocol, an end-to end-solution to crypt communication over XMPP". Cosimo and Eitan Isaacson are both working on encryption; Eitan has been plugging away at interactive certificate verification.

Andre Moreira Magalhaes is blogging to raise awareness of Telepathy-Qt4, a convenience library for people who want to use the Telepathy framework in their Qt applications.

And we've all been playing around with our N900 devices (Collabora company gifts). Tollef Fog Heen provides scripts & procedure to move SMSes and contacts from iPhone to N900, Felipe Zimmerle wrote an inclinometer, Jonny Lamb released a file transfer app and extra goodies to help you chat with people on lots of networks, and Thomas asks for testers for his new version of robotfindskitten.

Because we're hacking around, some of our apps you won't find in the default software repositories in the N900's applications manager. Here's a short guide:

Maemo Extras contains quality-controlled applications written by the community. It's installed on the device, but disabled by default.
To enable: Within App Manager, select "Catalogues" from the menu, find "", and untick Disabled.

Maemo Extras Testing contains the applications developers are preparing to update. There are lots of applications here and all need help in testing and validating. People can vote good applications up by visiting the application list; once enough people do that, an app moves to the regular Extras repo.

Still, these are not quite ready for prime time, so be cautious! One colleague offers this tip: "if you want to just find good quality applications within Extras-Testing, review this packaging list and find those with the most QA votes."
To enable: Within App Manager, select "Catalogues" from the menu. Click "New" and add the following details:

("Fremantle" means Maemo 5, the version of the Maemo operating system that the N900 runs. "free non-free" tells the manager that you want both open source and closed source applications; change this if you want.)

Maemo Extras-Devel: contains untested and wildly variant applications that might harm your system. Use this repository sparingly since the applications are unstable.
To enable: follow directions on the wiki.

Filed under:

(2) : Upcoming FOSDEM & UK Travel: I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting I'm going to FOSDEM, the Free and Open Source Software Developers' European Meeting, the first weekend in February. (Something like twenty of my Collabora colleagues will be there, including some I've never met before.) I've been to England & to Russia, but you can waffle around as to whether those are really Europe. But FOSDEM is in Brussels, Belgium! Very European, and makes its own waffles. I'll be arriving in Brussels a day or two before the conference proper. After it ends, I'll ride the Eurostar train (!) to England and see my Cambridge colleagues for about a week.

This is a management discussion trip and a seeing-people trip; as helpful as occasional facetime is for developers, it's essential for a manager like me. So, if you live in a bit of Europe or England such that it's easy for you to visit Brussels or Cambridge, I'd love to see you. And if you're giving a FOSDEM talk I absolutely must see, let me know! I'm interested in checking out:

(I'll have to put together a list of all the Collabora talks soon.)

Family continuity note: Seven years ago, Leonard went to Belgium for the European Python conference. I helped him brush up on his French, he hung out with Jarno Virtanen & Taina Prusti, etc., etc., etc.

Filed under:

: Some Recent Collabora Open Source Development: Has it been three months since I provided a snapshot of Collaborans' open source work? Too long! Here's a taste of our work from the end of 2009 & the start of this year (and there's a lot I'm leaving out, like a bunch of Maemo work, because otherwise this entry would go on forever! I'm already several days out-of-date): a few Collabora folks at dinner at Gran Canaria

The photos here are all from the Gran Canaria Desktop Summit last year, which was warm and fun. January (here in the Northern Hemisphere) is a good time to remember how nice that was.

Filed under:

(6) : Everything I Knew (About Battery Care) Was Wrong: Today I learned that I've been working from an obsolete understanding of how to keep my cellphone and laptop batteries from losing gobs of capacity over time. A simplistic summary follows for your benefit.

The batteries in my phone and my work laptop are lithium-ion batteries. Check yours -- the "Li-Ion" abbreviation means it's lithium-ion. As detailed sources explain, charging/discharging battery care for lithium ion batteries is the opposite of the conventional wisdom I had in my head, left over from the old days of nickel-based rechargeable batteries.

It used to be that you'd want to run batteries all the way down before starting to charge them again, because otherwise the capacity might get messed up. That's not true with lithium-ion batteries; it's recommended that you only rarely let an Li-Ion battery run down below 10% of its charge.

Lithium-ion batteries lose capacity, in the long run, if they sit overcharging a lot, or if they run hot a lot. So don't let them sit plugged into a charger all the time, and if you usually run your laptop plugged into AC power, think about removing the battery and setting it someplace cooler.

The moment a lithium-ion battery gets manufactured, it slowly starts losing capacity. So buying a primary battery + a spare battery simultaneously might be a worse decision than using a primary battery, then getting the spare battery years later, when your capacity has substantially degraded.

This came up because I assumed I should let my new N900 run down completely (on the partial battery charge from the factory) before plugging it in, and I was annoyed that plugging in the USB-to-microUSB cable to transfer files meant it was getting juice while the battery hadn't totally discharged. But I was wrong to worry! Thanks for straightening me out, Sjoerd.

Filed under:

: Can't Play Tour Guide Without A Map: GNOME Journal just published my Telepathy overview, and my colleague Danielle Madeley's "Telepathy, Empathy and Mission Control 5 in GNOME 2.28".

I'm not a developer, but I can at least help create accessible documentation. Telepathy world domination depends on accessible documentation: like the Telepathy book, but even more so. Newbs likely have trouble finding comprehensive overviews of some aspects of Telepathy: design issues, misconceptions, and the status of various efforts. They come to #telepathy (on and ask us questions, or just drop the idea of developing with Telepathy, or struggle in silence and make mistakes.

Danielle's book and article will help. I hope my article helps. I've made a small list of areas where I think a concise "here's the deal as of today" blog post or article or mailing list post (or wiki page clarification) would be cool. Basically, they're what I've had to learn to grok the direction & momentum of the project. I hope to create, improve or encourage friendly overviews of the following (in my Copious Spare Time):

(a) the major connection managers & their state of readiness/stability
(b) the up-&-coming CMs and their potential promise (e.g. yafono)
(c) mobile, Moblin, maemo-extras
(d) encryption/privacy/OTR/SRTP issues
(e) Muji/wocky work
(f) expanding our reach to KDE
(g) testy stuff like telepathy-ashes & echobot
(h) Teamgeist
(i) Python bindings

Anything to add to that list?

Filed under:

(8) : Here It Comes: The Queen has approved Leonard's dependent partner's visa, so it's now official: in about a month, we'll be moving to Cambridge, England, so I can work side-by-side with colleagues at Collabora headquarters. Many more details to follow.

Filed under:

(3) : Collabora Open Source Development Overview, 4-20 October 2009: Collabora, my company, does open source development. We don't just build on top of open source frameworks; every day, Collabora developers are hacking in the open on multiple projects.

I decided to blog about some of what we've done in the last couple of weeks.

First, our flagship project, Telepathy:

Collaborans also worked on Tubes, Teamgeist (part of Zeitgeist), Maemo packages, GStreamer, Farstream, and other projects. Just a few items, because it would be exhausting to cover everything:

Collabora also encourages its staffers to go to conferences to talk about open source. Last weekend, participants in the GNOME Boston Summit and the Amsterdam Maemo Summit led several discussions (Marco Barisione's Telepathy on Maemo slides are especially valuable).

And more FLOSS conferences are coming up soon: Gustavo will be at a WebKitGTK+ hackfest in Spain in December, and Helio will be at Latinoware 2009 later this week in Brazil.

Sorry to those I left out or didn't link. This list is obsolete even as I hit Post...

Filed under:

(4) : An Oversimplified Cliffs Notes To Telepathy:

Lots of people have never heard of my company or its projects -- even fairly plugged-in geeks often say "who?" or say "Oh yeah, the Subversion people." (No, that's Collabnet, where Leonard used to work.) So this post is specifically for my friends, to help explain one thing my company is doing that is cool. I'm going to simplify a lot so I hope my colleagues and other hard-core geeks don't wince too much.

It is annoying to have to log in to a bunch of different chat services to reach all your friends. MSN, Google Talk, AOL Instant Messenger, Bonjour, blah blah blah. You may not think this is related, but it's also annoying that if I want to work with someone on a document and we're at different computers, I can't use my regular word processor, I have to load up a web browser with Google Docs. And it's annoying to have your cell phone text messages (SMS) in a different place from your other chats.

These are all aspects of real-time communication. As my colleague Danielle put it,

The Telepathy project is helping solve all these problems. Telepathy is a project aiming to give desktop applications (like word processors, jukeboxes, CAD programs, and games) a way to painlessly integrate instant messaging and VoIP (voice over IP) telephony features. In more technical language, in Telepathy, Collabora aims to develop a real-time communications framework for the desktop and embedded devices.

My boss, Rob McQueen, was one of the Telepathy inventors, and I work for Collabora, the company he co-founded. We hope programmers will use Telepathy to improve your computer and cell phone and get rid of the annoyances I mentioned above, and create neat applications and services. We've already gotten started.

Here's one way of viewing the Telepathy framework. It has three essential parts:

  1. a bunch of Connection Managers, each handling the interaction with a protocol, such as Google Talk, XMPP, various VoIP (internet phone call) services, or AOL Instant Messenger
  2. Mission Control, managing accounts and channels (the individual protocol-bound pipelines that your messages go through)
  3. a specification, telling all the parts how to interact (very technical)

This design gives Telepathy a lot of flexibility. If a new interesting service comes along, like Facebook chat, we can just write a new Connection Manager for it and bam, anything that uses Telepathy can now interact with it. And there are a lot of text, voice, and video chat networks! Who knows what other interesting collaboration or communication networks might hook into Telepathy someday?

Another important aspect of Telepathy's architecture is D-Bus. Telepathy is primarily a project for the open source Linux operating system. It's built on D-Bus, a piece of Linux infrastructure that lets applications, frameworks, and low-level system components talk to each other. So that means Telepathy can act like a wormhole, not just between two different people's computers, but between unassuming regular ol' apps on their desktops. You and a friend can collaborate on writing a paper together right in your word processor, or play a game against each other. And you can do it without having to deal with a slow, limited web app in a web browser.

In case you are a geek and find this interesting: There's an entire online book with more detail, and a system overview with a pretty graphic. And of course we're an open source project and you're welcome to join us.

In the real world, even regular folks like you and I are getting the benefit of Telepathy with (for example) the new N900 smartphone. Evidence of Telepathy's awesomeness is in the addressbook -- it combines your friends' various text chat, phonecall, and other contact info in the same screen, rather than making you use separate programs.

I use Telepathy every day, because I use the Empathy chat program to talk to my AIM and Google Talk friends all in one tidy window. Telepathy has made some other cool applications possible; I wrote about them for the new Collabora website, and if people want, I'll post a little about those.

Note to self: in future posts, explain GStreamer, Farstream, WebKit, Electrolysis, and how we make money.

Filed under:

: Three Great Marketing Moves:

  1. Leonard and I attended a preview screening of the Coen Brothers' film The Man Who Wasn't There and got a promotional comb. We still have and use it, several moves later.
  2. I was chary of jumping into Battlestar Galactica without seeing the miniseries and all the episodes in order. Then one day, at the cash register at Midtown Comics, I saw a stack of free DVDs. Battlestar Galactica: The Story So Far. The iTunes store gave it away for free, too. I watched the clip montage summary and got sucked in, and from then on watched each new episode
  3. My colleague Thomas Thurman is blogging a tutorial on developing applications for the Nokia N900 smartphone.
Filed under:

: First: I'm in Boston for a couple of days, co-working with my colleague Andres Salomon, a.k.a. dilinger. He's been hacking on oFono on Collabora's dime, and last night's 0.4 release included work by Andres to add support for HTC G1 (the Dream) modem devices.

The oFono project is trying to be a well-designed interface to all the cell phone goodies -- texting, making cell phone calls, etc. Developers will be able to integrate their applications with the oFono architecture. With Andres's work, oFono now has its first working full-featured (voice calls + SMS) driver on a handset.

In case this interests you: Andres has uploaded a Debian package for oFono -- you should see it wend its way to the public soon. The future will also include a Telepathy Connection Manager for oFono; stay tuned.

Update: package accepted.

Filed under:

(1) : Blog Move And Thunderbird Tip: I've now moved from my old webspace at the Open Computing Facility (at the University of California at Berkeley) to space on a server that Leonard controls. So this is a test post to mark the divergence of those old archives and this now-canonical space for the blog at (redirecting from once the DNS propagates, etc.).

Let's have some useful content to keep it interesting: let's say you're using Mozilla Thunderbird as an email client, perhaps on Ubuntu Linux, and let's say you want your email replies to include the date of the email you're replying to. I found this tip helpful:

  1. use the Edit: Preferences dialog box
  2. go to Advanced
  3. click the advanced configuration editor
  4. type 'reply' into the filter box to search for configuration entries that include the string 'reply'
  5. click on the reply header type line
  6. double click that
  7. change 1 to 2
  8. close/OK all the windows, you should be set
Filed under:

(2) : Found Poetry: Inadvertently lyrical lines overheard at the virtual water cooler:

and if that package doesn't build, I'll need to give it another poke

and when we get the screen, we test and choose

I'm back in New York City.

Filed under:

(3) : More Notes From The Office: Sure, it's usually true that a job interview is going well if the conversation goes swimmingly, with no 90-second interruptions for explanations. But not if I'm interviewing a Brit. What's a second-class degree? What's a "supervisory" in this context? And so on.

From today's IRC conversation, after I pointed people to IKEA tumbler hacking:

* sumanah kills the entire company's productivity; secretly working for [competitor]
Filed under:

(1) : Obvious Tech Talk Q&A Prep: A certain species of tech talk goes like: "Here's a product/methodology/tool I hack on, here's what it's good for and how/why you should add it to your toolkit." It's an honorable and useful presentation topic. As you prepare your talk, think about the questions your audience will have in the back of its head. If you can address them in the talk itself, great. If not, prepare answers for use in the questions-and-answers session.

Common questions:

The most important question is the one you hope no one asks because the answer is embarrassing. What would your smartest enemy ask?

(List developed while helping Youness practice his libnice talk last week.)

Filed under:

(1) : The Home Office: I am finishing some berry tea from a ninja-logoed mug. I am in an office a few floors above the ground, across the road from King's College. I see English summer light and the college spires through the open window. We laugh out loud when someone says something funny on IRC, and then laugh again at someone's one-upping reply. It's Tuesday, so we're going to eat pizza at the two-for-one Tuesdays pizza place. The noon chimes just rang. I have a huge TODO list. Two of those items are making proper TODO lists from meeting notes.

I am happy.

Filed under:

: My Standby Joke: A few times in the past year, I've taken the risk of leaning over to an English-speaking stranger in the airport, one who's wearing a suit or the like, and saying, "Ah, the glamor of business travel." It hasn't yet failed to get a laugh.

Filed under:

: Gran Canaria Talks by Collaborans: I think this is the complete schedule of talks that my colleagues are giving at the Desktop Summit this year.

Sat. 4 July
"QtScript bindings for Telepathy" - lightning talk by Ian Monroe, 15:30-16:30

Sun. 5 July
"The location-aware desktop" by Beaudoin, Pierre-Luc with Henri Bergius: 11:30, Room 2

"Profiling and Optimizing D-Bus APIs" by William Thompson: 12:30pm, Room 1

"Integrating VideoConferencing into Everyday Applications" by Olivier Crete: 12:30, Room 4

Tues. 7 July 2009
"Let's make GNOME a collaborative desktop" by Guillaume Desmottes: 11:00 - 11:45

"How to play libnice-ly with your NAT" by Youness El Alaoui: 15:00

"Pitivi Video Editor" by Edward Hervey: 15:45

Thurs. 9 July 2009
"Introduction to GStreamer development Tutorial" by Wim Taymans: 15:00

Fri. 10th July
"Tools for Authoring Awesome Docs" by Davyd Madeley: 11:00

Filed under:

: Getting (Irrelevant) Things Done: I am bikeshedding my own yak-shaving. This should win an award.

Filed under:

: Travel Schedule: I'm going to the Gran Canaria Desktop Summit next week. Developers, managers, and other free software enthusiasts in the GNOME and KDE communities get together on the Canary Islands, which are technically part of Spain but sit off the coast of Africa. Then I spend a week in Cambridge, England, working alongside my fellow Collaborans. Yup, it's all for work, and I won't even think about bringing a suit (other than a bathing suit).

Filed under:

(3) : On Dentistry: I went to the dentist last night, specifically at the NYU College of Dentistry. I actually prefer the dental school experience to many private practice dentistries. The wait in the waiting room is shorter (2 hours per appointment actually spent in the chair, rather than an hour in intermittent waiting plus an hour in the chair), I get treated by eager-to-learn dentists in training rather than bored, laconic hygienists, and the student dentists are thorough and communicative. And they offer a 6pm-8pm slot. Very few private practices do.

Young student dentist Stringer was the one to phone me up to set up an appointment. He was more deft, gentle, and patient than several DDSes I've patronized. "Oh, you build up a lot of calculus here, because of your salivary gland. I have that too," he confided. He checked in with me about whether the ultrasonic cleaning dealie was running too hot and hurting me. "I don't like to use it, I don't think it's gentle enough," he said. He handed me the suction wand: "Raise your hand if you need me to stop so you can suction."

In further stereotype-demolishing, Stringer does not play World of Warcraft (nor does he wear Ira Glass glasses). My cousin-in-law-in-law Aaron, husband of Kristen, is on the road to full Dentistdom and enjoys WoW-style games. [pun about grinding omitted]

I told Stringer what his last name means in journalism; in retrospect, he has a new occupational surname, like Smith or Cooper.

I get curious about others' occupations. Firefighters, CAD designers, directors, transcriptionists, silversmiths, pastors, teachers, full-time caretakers, taxi drivers, deli owners, X-ray technicians, soldiers, construction workers, dentists. How does doing your job change the way you interact with others?

Filed under:

: Translation Of A Truth: I reread much of Neal Stephenson's Cryptonomicon a few weeks ago and found this passage:

"We're businessmen," Avi says. "We make money. Gold is worth money."

"Gold is the corpse of value," says Goto Dengo.

"I don't understand."

"If you want to understand, look out the window!" says the patriarch, and sweeps his cane around in an arc that encompasses half of Tokyo. "Fifty years ago, it was flames. Now it is lights! Do you understand? The leaders of Nippon were stupid. They took all of the gold out of Tokyo and buried it in holes in the ground in the Philippines! Because they thought that The General would march into Tokyo and steal it. But The General didn't care about the gold. He understood that the real gold is here--" he points to his head "--in the intelligence of the people, and here--" he holds out his hands "--in the work that they do. Getting rid of our gold was the best thing that ever happened to Nippon. It made us rich. Receiving that gold was the worst thing that happened to the Philippines. It made them poor."

--p. 858, paperback

"Our wealth is work," the man said.

More decade-old Stephenson analysis coming later tonight.

Filed under:

(4) : Learning: In the last two weeks, I have learned rather a lot about configuring and troubleshooting usage of Empathy, Telepathy, Synaptic, PPAs, git, TeX/LaTeX/dvi, gtimelog, IRC and bip, RSA SSH, and XMPP. Well, it was a lot to me.

I've also learned that if I want to get up around 6am consistently, I have to go to bed around 9 or 10pm consistently, and that if I work in a windowless rented office then I won't know till I leave that it's raining. So I'll just be making a cameo at the io9/ shindig tonight, and I'm trying to pay attention to the weather symbols in the clock gadget in my taskbar.

Filed under:

: Ramping Up: In my first week at Collabora, I've learned that I can stand to poke at .conf, .rc, and similar files for at most two hours out of my working day. I've also learned that the Ubuntu version of Firefox doesn't give me a warning if I hit Back after typing form data on a webpage; not sure how to fix that. The Lenovo x200 ThinkPad is light and small, and I'm adjusting well to the nub-mouse, but there's a dedicated Back key right where my fingers think the left arrow key is, which gives me a few "arrghs" a day. I may dedicate some fiddling time next week to disabling that key. And I renew my grief that IRC is not a common feature of every office environment.

As lead project manager I'm to keep on top of all the work we do, for clients and for the community in general. So this week I've been drawing diagrams of technology stacks and who's doing what, and memorizing thirty real name/IRC nickname pairs. If I were Juanita from Snow Crash I would be developing face-based avatars for all my new colleagues, but since I am not perhaps I should get a bunch of Dungeons & Dragons figurines and set them up on a campaign map representing VoIP, embedded Linux, mobile, etc., etc.

Filed under:

: This Retrospective, In Retrospect, Has A Theme: An abbreviated diary of the past few days, mostly for future Sumana's use:

Wednesday I went to Supper and the Sci-Fi Screening Room with a journalist who opines that it's his God-given right to drink scotch at his desk when he's on deadline.

Thursday I saw Tim Wu, Stuart, Jena, and Hailey as we hashed out next steps and plans for AltLaw. I stopped by Midtown Comics after; Hal had put aside the new Ambush Bug compendium for Leonard.

Friday night: Matt Weinstein, an old Berkeley pal, came to town, so I met him and some friends of his at The Silent H, a shockingly good Vietnamese place in Williamsburg. At Queensboro Plaza on the way there, I talked to a guy who was reading Cryptonomicon on the platform, and envied aloud that he's on his first reading. At the restaurant I met a Captain-Hammer-shirt-wearing friend of his who cemented his worth by trading Cryptonomicon references and quotes with me for twenty minutes.

This morning: breakfast and The Met with Anne and her sister Sarah, Anne being a woman I met online when I sought WisCon attendees who'd let me sleep on their floors. We got along great and I'm sure I'll learn a lot about scifi fandom from her. At my place, this evening, I did some career coaching with my friend Rebecca and helped her improve her LinkedIn profile.

In conclusion, dorkiness got me everything I adore in my life.

Filed under:

(3) : If You Read This To The End You Get To See Inside My Marriage: I watched the interview Jon Stewart did with Jim Cramer a few weeks ago. If you're the kind of person who loves Jon Stewart's work, you probably heard about it.

Stewart's key critiques of CNBC:

Financial news that focuses on short term profits and stock tips is an unhealthy market force. Financial reporting has a responsibility to be skeptical of too-good-to-be-true profits and investigate companies and trends that produce them. Finance experts who know about a house of cards have a responsibility to tell the public. It's irresponsible to cheerlead unsustainable bull markets, persuading laypeople to invest in "responsible" retirement plans, then blame evil CEOs and weak regulators after the inevitable crash. Saying people can get wealth without doing work to create value is disingenuous and possibly criminal.

Salon followed up on many of these substantive critiques, not just following the blast and noise of Media Titan Confrontation. "On "Mad Money," Cramer back to normal": he was contrite on the Daily Show, then the next day he minimized the whole thing and kept on doing his normal schtick. More insidiously, "There's nothing unique about Jim Cramer: The mindless complicity in disseminating false claims is not aberrational media behavior; it is, as they acknowledge, the crux of what they do." Greenwald compares recent finance reporting to prewar Iraq reporting.*

Stewart's most controversial point, and one that hasn't been discussed as much in the mass media, is in the last part of my summary: cheerleading unsustainable bull markets, and encouraging investment rather than work as a way to wealth, is wrong. His words:

But isn't that part of the problem? Selling this idea that you don't have to do anything. Anytime you sell people the idea that sit back and you'll get 10 to 20 percent on your money, don't you always know that that's going to be a lie? When are we going to realize in this country that our wealth is work. That we're workers and by selling this idea that of "Hey man, I'll teach you how to be rich," how is that any different than an infomercial?

"Our wealth is work...we're workers." I asked Leonard to help me figure out why, when a political candidate praises work and workers, it sounds like cant, but Stewart's phrasing felt subversive. He pointed out that the word "workers" and identification with the working class remind people of Marxism. Oh yeah, that. Also, "wealth" usually means earnings and/or capital -- cash, real estate, securities, some financial instrument or an item that can be sold in the open market for cash. But Stewart is saying that our wealth, the prize that we've earned, isn't money, but our ability to earn money. Our asset is the ability to create assets.

Again, identification with the working class. But it's a short step from that to rabble-raising populist demagoguery, which Stewart and Colbert make fun of. A lot. Possibly while engaging in it.

'You say ... I want to keep this homicidal fury forever!' [side-annotation: Hysteria, Our Only Growth Industry] 'But, Stephen, your Thunderdome idea will kill all the CEOs, and there'll be no one left to force through the man-sized paper shredder!' But I say: we will never run out of scapegoats. Because if we focus on pitchforks and vengeance, instead of the fundamental problems that got us here, soon, we'll have plenty of new criminal banks and irresponsible CEOs to start all over again. And we can cry 'Off with their heads!' -- and we'll never have to keep ours.

I get annoyed that the TDS/TCR audience cheers so loud, gilding the lily at every punchline. But sometimes their silence is a tell. When Stewart tossed off that key phrase, "our wealth is work," and when Colbert made his point about scapegoating, the audience was too stunned to clap. This reminds me of a similar moment from Colbert's interview with Daniel Gilbert, happiness expert, June 27, 2007, about 3:45 into the interview:

DG: "It turns out that kids have a very small effect on people's happiness, and the effect tends to be negative. But you'd be happy to hear-"

SC: "Wait wait wait..."

DG: "Well, it means that people with children tend to be a little less happy than people without them, and the more children they have, the less happy they turn out to be."

SC: "Now, are you confusing happiness with the feeling of the sublime? Because children are a pain in the ass. Okay, I'll grant you that. But the feeling that comes with children, I have found, is a feeling of -- that is superior to happiness."

DG: "Yeah, of course."

SC: "That is the sublime feeling. And the sublime comes from beauty."

DG: "The happiness that children give you is a little like the refrigerator light. Every time you look, it's on. Every time you think about your kids, you're happy. The problem is, they're a pain in the ass more often than you're thinking about them."

SC: "Well, that's interesting."

So this is a big shaggy dog story where I end up trying to convince Leonard, who enjoys Colbert but doesn't like to watch the interviews, to start watching the whole show. Because sometimes stuff like that comes out, where you see the real Colbert peek through, this witty improv-loving geek with a background in Catholicism and Tolkien. Basically, it's the Brendan Leonard show!

* Salon, ProPublica, New Assignment, and similar ventures are trying to do good journalism that avoids the inherent blindspots of traditional mass media. In a similar vein, I'm fond of Fred Clark's suggestion that a Work section replace the Business section.

Filed under:

(7) : New Awesome Work: Martin and I are co-founding a new firm to produce the PoTeaTo, a food-and-beverage convergence device targeted at the United Kingdom and the Republic of Ireland. Simply drop the PoTeaTo into a small pot of boiling water and watch the seam split, revealing two pre-blanched potato halves and one strong teabag! Boil them together and you'll have a meal and the drink to go with it.

Just kidding. Actually, starting in a couple of weeks, I'll be working at Collabora, an open source consulting firm. I'll be managing projects and helping them develop awesome tools like the Telepathy framework and the Empathy instant messaging/IRC/VoIP/video chat application. Yes, people are using the phrase "Skype-killer."

I'll get to telecommute (casual day every day!), advance the cause of Free/Libre/Open Source Software, and facilitate the work of dozens of geeky colleagues around the world.

Exciting! The PoTeaTo shall have to wait (in a dry, dark, cool place).

Filed under:

: The Long View: Throughout Jody Procter's memoir Toil: Building Yourself, a diary of his work helping build one specific house in a small Oregon city, Procter aches for the weekend, feels hopeful and buoyant working through Friday afternoon, and buys himself little treats at the 7-11 on the Friday drive home. The rhythm of building tension and weekly release thrums over and over again. The end of the March 17th entry:

I have been taking my watch off or leaving it in the car to try to keep from looking at it. 10:56. 2:05. Seeing those dead hours in the middle of the day demoralizes me. Now, this afternoon, I put my watch on, the better to savor the slow pace of the last hour and a half of the week. The sun has disappeared. The clouds rolls in. A few sprinkles fall and the air is cool and fragrant with the budding flowers of spring and the moist, freshly cut grass of the golf course. I am happier and happier as the final minutes of the work week tick by.

On my drive home I think, if you could only bottle that Friday after-work feeling and sell it to people, you could make so much money you could stop work and then you would never have that Friday after-work feeling again. Unless you indulged in your own product. And probably, after a while, you'd get addicted to it, it would lose its kick, it would turn out to have negative side-effects and all would be lost and in ruins. You would lose your fortune and have to go back to work and then some Friday you would be driving home and you would have that Friday after-work feeling all over again.

Filed under:

: A Book Review About Leadership: I mostly wrote this book review in the fall of 2008.

On the Psychology of Military Incompetence

by Norman Dixon


On The Psychology of Military Incompetence is 400 pages long, and worth savoring. Its fundamental question: Given that information is the reduction of uncertainty, how do leaders of different temperaments react to information? The author limits himself to cases of British incompetence in battle, but of course you can extrapolate from that.

Dixon clearly but steadily builds his case against the prewar British military. The one-line summary is: culture stagnates into convention, which drives out the unconventionality you need to succeed. More nuances ahead.

From Skeleton to Prison Cell

Dixon shows that to advance in the British armed forces, in peacetime, demanded rule-following and an authoritarian mindset. But the mission of a military is to win wars, and that requires fluidity and a willingness to take risks -- and offend superiors.

So, what happened when peacetime promotions hit a war zone? Disaster -- in the Crimea, in southern Africa, all over Europe in the First World War, over and over again. Soldiers' courage and tenacity get their generals out of the holes they dig.

In general, institutions get the leaders who fit into those institutions and succeed at the unstated goals (for example, avoid retreats at all cost, impress politicians, keep civilians uninformed and complacent). If the unstated goals don't line up with the institution's stated goals, then leaders will tend to do the things they've been rewarded for in the past, especially in moments of high stress and low certainty. Therefore, in battle, bad commanders freeze up, wait for orders, ignore new information to appear "decisive," give panicked and contradictory orders, lie to maintain their personal reputations, and so on. And disaster happens, over and over again.

In Dixon's view, the British military suffered from groupthink and valued particular upper-class traits over merit. It's astonishing that military personnel would need to be told that the map is not the territory, the signifier not the signified, but indeed they cared more about the signs and forms of morale and professionalism (such as clean clothes and polished brass) than about warm clothes, edible food, and working equipment.

Narcotic Assumptions, Lenses & Blinders

I'm in India as I write this and dealing with my own need for shiny appearances. I often forget, once I return to the States, that I find -- for example -- hermetically sealed bathrooms reassuring. My parents live in a home where the plumbing and electrical work aren't consistently hidden beneath stucco and sideboards, and it surprises me how much that bothers me. I haven't seen any marked crosswalks in their city, either; we watch for a lull in the bicycles, mopeds, and rickshaws, then rush over the dusty, rocky street. No accidents yet.

I consciously desire function over form, but that only works if I can convince myself to rely on an ugly-looking system to work.

I calm myself with a fallacious appeal to statistics: if something's wrong, it would have broken already. If other people depend on similarly rickety-looking setups, then they must be dependable. Or I just go straight to infantilism and believe my parents wouldn't put me in danger.

Seth Godin recently wrote about the "edifice complex". He reminded us that, in times of uncertainty and stretched budgets, when we can least afford the "organized waste" of facades, we find them most reassuring.

In good times, insecurities and rationalizations like mine are a luxury. In battle and competition, they're delectable poison.

British commanders, similarly, clung to the false clarity of their chain of command, "masculinity," pride, and privileges when they faced the mess of battle. They feared shame more than they minded losing men, and they scorned the "motherly" chores (or retreats) that would ensure troop survival and readiness.

Valiant forays are masculine, but feints and retreating are girly? Again, ideology got in the way of success, as when insecure commanders pooh-poohed nonwhite adversaries, self-improvement, and new technology.

The lesson: Real self-confidence doesn't need ideology as a crutch. The flipside: if you see someone leaning on received assumptions, and repeating them rather loudly, it's because without them he wouldn't know who he was.


The argument above takes up most of the book. In an aside, Dixon suggests that "senior commanders have often to fill a number of incompatible roles": heroic leader, military manager, and technocrat, plus politician, PR man, father figure, and therapist. This is of special interest to me.

I've learned models describing styles of leadership: authoritarian, democratic, and whatnot. These days I'm more interested in the balance among managing up, down, and sideways. Reading these books and thinking aloud about them helps me get perspective. What leg of that tripod have I been shorting?

Works thematically related to On the Psychology of Military Incompetence: Dilbert, the Harvard/NASA case study on the Columbia shuttle disaster, and John Le Carre's The Tailor of Panama.

Filed under:

: Ada Lovelace Day, Belatedly: I am abashed and thankful that Rachel and Danny thought to mention me in speaking of women in tech on Ada Lovelace Day. I offer a sidelong glimpse into a short list of my influences Right Now Today:

A woman, my manager at Exodus, a history major or something, whose career path reassured me that CS wasn't the only way into interesting tech jobs. I thank you, Jed, for making a similar point -- QA, tech writing, education, design, sysadmin, and management are damn cool.

Marissa Mayer at Google might be, among other things, Google's Steve Jobs, and inspired me to think more about product design leadership.

Rachel Chalmers, of course.

Mel Chua, who reminds me to learn about how I'm learning, and that my default answer should be "yes, I can do that."

And all my Systers. I thank them for daily popping up in my inbox, being the friendliest forum for questions stupid and subtle, and reminding me that we are legion, diverse, wage slave and entrepreneur bare-metal hacker and CIO and everywhere in between and sideways.

Filed under:

: Lego Learning: When I was rejecting submissions for Thoughtcrime Experiments, I told many writers that I'd give them suggestions for improvements if they wanted them. Some replied and took me up on the offer. Today I'm working on some of those critiques. Suddenly I am interested in litcrit theory and practice, because now that is a tool I can use to help people.

Filed under:

: Haze Outside, Malaise Inside: Seeing old friends makes me feel homesick. Going to more free culture events here may help. Also, distractions! Like HOWTO/memoir books about other professions!

Zac Unger's Working Fire, about a guy who basically leaves academe to become a firefighter, is short, switching between journalist-clear and memoirist-thoughtful. My ex's dad was a firefighter in Stockton, probably still is. When I try to remember what he looked like, I think of my old boss Leonard Pollara of Upper Meadows Farm. I once had Thanksgiving dinner in a firehouse with his family and remember feeling very nervous and out of place. Unger had the same fears but got over them, partly through competence, partly by adapting his social self and making friends.

I'm nearly done with Jane Addams's Twenty Years at Hull House, which chronicle the doubt, missteps, victories, and idealism of the young and middle-aged Chicago community organizer from the turn of the century. I was reassured when Addams talked about her long, hazy post-college period before starting Hull House. I haven't come up with my Big Project yet -- I'm not just waiting to be struck by certainty, I'm searching for what my unique value even is -- and every day I feel like the clock is running out.

Filed under:

: Log: L. Sprague de Camp's entertaining Lest Darkness Fall moves really fast. This is probably true even if you haven't just read a 900-page Neal Stephenson novel. I nearly mentioned Lest Darkness Fall in my brain candy recommendations to danah boyd, but fear it's not trashy enough.

William Ball's A Sense of Direction is fantastic and as soon as I return it to the library you should check it out. As I suspected, it has a mix of great inside baseball on directing plays (e.g., three pages on how to structure and practice curtain calls so that actors don't get their egos in a twist) and transferable advice on managing creative folk.

We learn in threes. The first step of learning is discovering; the second step of learning is testing; and the third step of learning is pattern-setting.

The actor will learn to relinquish his fear when he sees that the director never causes another actor to be frightened.

...a question from an actor is not a question. A question from an actor is an innocent bid to draw the director's attention to something unresolved. When the actor asks a question, a wise director doesn't answer the question. The answer to the question is not in the director; the answer to the question is in the actor. Answer the question by asking another question. Allow the actor to resolve the difficulty. He already has the best answer in mind before he asks the question.

Always begin rehearsal on time. There are some directors who like to gossip and joke and waste the first ten or twelve minutes. This awakens a sense of sloppiness in the actor and gives him the feeling that the work is not important.

For future reference, I'm also a fan of advice on pp 58-59, 66, 102-104, and 108 of the 1984 edition.

This weekend (among other activities) I went to a fun party, watched a lot of Babylon 5, saw a friend's wife and new baby, read the de Camp, ate Leonard's excellent sour cherry cobbler, walked around a lot, filed a bug or two on Miro, and rented movies to foist on my fellow jurors this last week of grand jury duty. All this and I still spent hours dinking around on the Web. So there, anxieties!

Filed under:

: Questionnaire For Vendors: We got a demo of a fancy new web-based software tool -- project management, task tracking, bug tracking, collaboration, Agile, Extreme Programming, a singing, dancing, iterating revue. I know a little something about the tradeoffs that creators of collaboration tools have to make. So I could ask pesky questions like:

I don't think the vendor liked that I was asking these questions. I got the nervous-laughter/"That's a very good question" combo twice. Good sign.

I can come up with more such questions for vendors in case anyone feels like lengthening their checklists. Share yours in the comments.

Filed under:

(3) : Gems: I post lots of little links in the account that Leonard and I share, and that keeps this blog from just being a mass of commentless links. But every once in a while I wish to celebrate bits of the net with/at you. Here!

If you can't get enough Randall Munroe, his LiveJournal should absorb you for ten to twenty minutes. Munroe's experience of Cryptonomicon and mine concur: "I keep picking it up to glance through and then accidentally reading through to the end." Sadly, Knuth, Stephenson, et al. are probably too busy with their magna opera to enjoy the thrice-weekly distraction of Munroe's work.

The soldiers' truce of 1914 -- I knew about it, but it turns out I didn't know a tenth of the story. Tremendous.

And, in a discovery almost certainly irrelevant to your life and to mine, I think Pseudonymous Kid's mom's dad lives where I used to live.

But the real hot tip of this entry is Yishan Wong's Reddit comments. Wong works at Facebook, his wife just had a baby, and I'd rather read his comments on Reddit than blog posts by jwz or Steve Yegge. Examples:

Abortion clinic bombers are the only terrorists who can accurately be described as "hating us for our freedoms."....

It's not one bad programmer. PHP makes bad programmers worse, but it also forces good programmers to have to be kind of bad just to get things working "okay."

What's remarkable about PHP is that it's the best PHP programmers who are the ones most vocal about how awful it is....

Just for irony's sake, I use [the powerful chip in the Sony PlayStation 3] to crack the encryption on my Blu-Ray discs.....

But the bit I really love, the bit that throws Paul Graham into the water, is Wong's encouragement and HOWTO on learning to work hard.

...One bonus effect is that you learn what smartness really does for you: it's a multiplier. It doesn't give you success for nothing (i.e. 5000 x 0 = 0), but if you apply smarts to a work ethic, your output is multiplied (i.e. 5000 x 10 = 50000). So a smart person who learns to work hard benefits far more than a mediocre person who works hard.

This benefit becomes very addictive: "whoa, by sheer force of will I can essentially call into being wealth for myself!" and that's what keeps you from backsliding....

That's going on my reread-regularly list.

Filed under:

: Here We Go: In this week's MC Masala column, Leonard talks about making pesto, and I talk about the Indian tulsi plant.

Leonard used the garden as a trick to get himself to exercise. His hours of plantings, weedings, waterings and harvests yielded about five meals' worth of food. But he still remembers sharing those green beans with our neighbors. And that yard went from dead gray dirt, where not even weeds grew, to a beautiful green/brown profusion.

My mom gardened everywhere she lived, too. I remember the flowers best. All our houses smelled of jasmine -- Leonard included a jasmine vine in our backyard to make me happy. But she always made sure to grow one herb: Tulsi, or 'holy basil.' We ate it and we used it in Hindu ceremonies. No wonder I latched onto its cousin, the sweet basil that we usually mean when we say 'basil.'

I finished Neal Stephenson's The Baroque Cycle. As always, some nice metaphors and insights, but I didn't get enough jaw-dropping moments out of the thing, and it got to the point where any clump of description longer than a few sentences tripped me up. Still: an awesome achievement, and the dialogue where Daniel Waterhouse meets Mr. Orney is deadly hilarious. Also, I recently read Isaac Asimov's crazy Murder at the ABA. Harlan Ellison didn't sue for libel?! And An American's Guide to Doing Business in China: Negotiating Contracts And Agreements; Understanding Culture And Customs; Marketing Products And Services by Mike Saxon is fascinating, especially in the vivid, deep, broad stereotypes of China and the Chinese.

I'm off for two weeks for my own exercise and green/brown profusion. Via WWOOF, I'll be working on an organic farm a ways northwest of here. Mostly tending tomatoes, I believe. I got a sun hat and some shreddable shorts and jeans at the thrift store. I leave tomorrow. If my schemes work out I'll still get a copy of the seventh Harry Potter book the day it comes out and read it before spoilers get to me. Also if my schemes work out my first time ever doing agricultural work will not maim or kill me.

Filed under:

(2) : Update Re: Resumes: Yes, you write a customized cover letter for each job application.

Filed under:

(1) : Tip For Keeping Resume To One Page: Copied and mildly edited from my comment yesterday on the Joel On Software discussion board. The original poster, two years out of college, had asked whether to keep his college internships on his resume - and if so, how could he keep the resume down to one page?

Like any fairly ambitious person your age, you've got enough accomplishments, internships, gigs, volunteering, awards, etc. to fill at least two resume pages (reasonably typeset). That's great. So create that and keep it updated. That's your mega-resume. For each job, you have several bullet points listing all your tangible accomplishments and regular tasks you performed.

Then, for each individual job that you apply to, distill down a relevant one-page resume, with each item specifically selected for the job description and the research you've done on the organization. (You label your past gigs as "Selected Work Experience" so it's clear that this isn't all you've done. "Additional work experience and references available on request" is the last line.)

Once you're distilling a new resume for each job application, you clearly see that sometimes you should include internships, and sometimes another experience earns that space on the page. By the time you're 7-10 years out of college, you'll almost never find space for an internship on the one-pager.

If you're lacking space for a particular one-pager but want to convey your leadership skills, your experience in teaching could go in your "skills" section.

A few slightly off-topic tips:

1) Acquaintances and friends of friends are a better source than posted job ads. Talk to the most connected tech people you know, even if they're just acquaintances, and ask them to keep their ears open for opportunities for you. A personal introduction is a less brittle stepping stone than a resume.

2) Your mileage may vary, but the fact that I put "stand-up comedy" in my public speaking skills/experience line on my resume has piqued hirers' interest more than once. If you have a non-creepy hobby where you've accomplished a lot, think about putting it in the Skills section.

Filed under:

: Trepidation And Excitement: Today at work I got to coordinate the creation of a neat thing. That excited me. Tomorrow I defend the first chapter of my product proposal for my master's degree. That's more scary.

Filed under:

: Straw Men: Did I ever tell you about the striped straw experiment and deciding to be happy? From a column I wrote about a year ago:

...straw fortune-telling, or bendymancy. For breakfast every school morning, I had a bagel with melted Velveeta and a cup of Carnation Instant Breakfast -- not the complete and nutritious meal that my mother would have preferred.

I drank the shake through a straw (Bendy, not Krazy -- after all, I wasn't a baby). Mom bought these straws in 500-packs from the Pak 'n' Save, which printed grocery packing directions on its brown paper bags, headlined with the educational but dismissive "Pack Your Own Savings!"

These white straws came with assorted stripe colors, one quarter of the box was red, one yellow, one blue and one green. I decided that the stripe color of the straw I randomly chose would foretell the quality of my day. Red was horrible, yellow was unpleasant, blue was good and green was great.

And if that makes sense to you, you should read Mark Haddon's "The Curious Incident of the Dog in the Night-Time," in which an autistic boy decides to make up his own fortune-telling superstition.

Even if I knew it was all fake, even if I drew a red-and-white straw, at least it gave me a worldview, some resignation or confidence so I could frame the events of the day.

The things I decide to do on my own feel so much better. Learning a bit of Scheme, exercising, going to church, climbing a rock, whatever -- the very self-direction makes them taste sweeter. But I still need another person's support or company to keep doing them. So that's one balance to hit.

I learn skills best when I've created a goal that I sincerely want and that requires those skills. Until I want that goal, it's useless. But what do I want? Desire and agency feel so far away, even though I have demonstrably chosen things towards certain preferences. All I consciously own are the lower-order needs. I'll second-guess any consciousness of ambition. What makes me feel joy, just for a moment, is fulfilling the ambition that I'm too suspicious of -- and too enamored of laziness masquerading as rat-race-avoiding contentment -- to wholeheartedly chase.

The world is not finished. I'll never master things. How is it that some people find that energizing? I can understand how existentialism turns some to nihilism and some to humanism. I think I'm struggling along, finding some structures readymade and creating some, awkwardly, secretively, on my own. I feel less like an oak and more like ivy seeking a trellis, even though sometimes I dare to look down and can't quite see the scaffolding I've assumed was there.

[Update: Nothing is finished, and that is a comfort because that means we haven't permanently failed, either.]

Filed under:

: Between Transparency And The Paywall: You are important. You are worthwhile. Your time and effort have value. Right now, a very good way to indicate and articulate and leverage your value is by making sure you get money in return. And it is okay to make more than you absolutely need.

From The West Wing:

Josh Lyman: I know that you can parlay the Santos win into a doubling of your fee.
Louise Thornton: Tripling, if it figures into your memoirs.
Josh Lyman: Nothing is going to top this. Everything else's going to be a letdown.
Louise Thornton: Letdowns that make me semi-rich, that's a tradeoff I'm willing to endure.
Josh Lyman: You don't care about money.
Louise Thornton: Who doesn't?
Josh Lyman: You!
Louise Thornton: Not as such.
Josh Lyman: As what?
Louise Thornton: Scorekeeping. Quantitative evidence that I'm smarter than you. (Not YOU.)
Josh Lyman: Who?
Louise Thornton: Everybody else.

Prices send signals; one way for me to make sure Salon valued me was to get them to give me a raise. "Doing things that make work rewarding and pleasant is the most important part of attracting people." Once I'd hit the ceiling at Salon, and the work wasn't rewarding or pleasant anymore, I started looking for other work. But in the meantime, I got a raise from Salon to compensate me for my experience, value, and not-leaving-ness.

The easiest way to get a raise is to get a new job; a big jump in pay happens easier when you first get hired, while you still seem shiny and exotic and new to the new employer. But if you can get a raise from your existing employer, then the new employer will have to raise it to get you. So I make as much as I do at Fog Creek partly because I got that raise at Salon. Salaries accumulate over time, like compound interest, so getting up the ladder has long-term effects.

John Scalzi talks about how much he makes and talks about why he talks about it. I don't feel comfortable talking on the web about all of my finances without asking my husband first, because they are now his finances too. But I will tell you that I make $75 per column for my weekly MC Masala gig, and that I'd like to be making more from that, since I have delivered for two years now and built up a small fanbase and have a circulation in the hundreds of thousands. This summer I'd like to seriously look into syndication.

The more information we wage-earners and freelancers share, the better we can negotiate with the employers. Whom does it benefit when we are reticent in disclosing the pay scale of the world?

Filed under:

(3) : Riddle Me This: I work in a software firm. I am the only person there, except the office manager, who is not a born-and-bred computer geek. They play video games all the time. Yet I'm the only one who regularly walks in reading comic books, and who makes Star Trek references that no one understands at the lunch table. Worst....stereotype....ever.

Note on my objective weirdness: I've also been bringing in MAD Magazine to put next to Linux Journal for bathroom reading.

Filed under:

: Anatomy And Andragogy: Yesterday, I sat down over coffee with the Fog Creek system administrator and learned how a specific piece of our network architecture works. As he talked and I asked questions and tried saying things in my own words, and we drew diagrams and annotated them, I learned something about how I try to understand a complex system.

  1. First: the big parts/components and their functions.
  2. Next: understand the desired and usual flow of data/blood, from entering the system to exiting it. Here I try to see things from the perspective of a single data packet, blood cell, or what have you.
  3. Next: what's enforcing the rules, and what's pushing the data/blood through the system? What are possible attacks or failure points? And what defenses are built in to resist or recover from attacks or failures?

Without even meaning to, I was taking Neal Stephenson's advice to heart:

Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic....

...Unix has slowly accreted around a simple kernel and acquired a kind of complexity and asymmetry about it that is organic, like the roots of a tree, or the branchings of a coronary artery. Understanding it is more like anatomy than physics.

--Neal Stephenson, "In The Beginning Was The Command Line" (1999)

So I've articulated a possible plan of attack for learning computer-related architectures. Another: just dig in! Try something small and concrete, and learn as you go. But I've found that, once I try to do anything even mildly complicated with OSes, filesystems, networks, and what have you, I get quite uncomfortable unless I can find out the structure and foundations of the domain. So now would be a good time for me to take classes in data structures, algorithms, networking and architecture, etc. Maybe I'll make my own summer crash course.

Filed under:

: Minimalism: Just got off the column for this Sunday. Something I had to leave out: Mike Daisey wrote about his time at Amazon in his book 21 Dog Years (based on his monologue) and talked about dot-coms and minimalism in architecture for a paragraph.

I don't know what it is about tech companies and exposed ductwork -- they love the stuff. It's as though the building's guts reflect an inner anxiety writ large, so that at any point in the day any of us can look up at the exposed piping and exclaim, "We're so busy, look how hard we're working...oh God, please, we're almost profitable, we're working so hard that we don't have time to cover up these ducts! They had to be exposed! That's how dedicated we are!"
Filed under:

: To Optimize Response Speed On MySQL, Follow These Instructions: Just watched Jay Pipes's 45-minute Google TechTalk, "Performance Tuning Best Practices for MySQL". A few points I took to heart:

I've just listed a few of the best tips. If you deal with MySQL for fun or profit, check out the talk.

Filed under:

: Tech Concerns Great And Small: David Stutz's essay on commoditization, software platforms, and the law of "the conservation of attractive profits" reminds me: software is profitable when it is flawed. This is because flawed software allows you to charge for bugfixes and new features, and because flawed software is an indication that the state of the art does not yet solve customers' needs, so they are hungry and it's a seller's market.

Today I've been working with Microsoft SQL Server Management Studio Express for the first time. This is actually my first time getting my hands dirty with any of the Microsoft database management applications; I've used phpMyAdmin to talk to a MySQL database, but that's all. Microsoft has a reputation for doing exactly what Stutz is talking about. Create a barely adequate product and get people using it, charge them for upgrades, and create a strong network effect barring market entry. Turn your technology into the platform that other people build on, by default. Collect rent.

But my recent experiences with IIS, SQL Server, and other grown-up-ish Microsoft technologies are cooling my old Slashdottian zealotry. I'm like Randy Waterhouse reluctantly recommending Windows NT to his oral surgeon. Troubleshooting in Windows involves undocumented API changes, wizards that improperly wiz, and unchecked-by-default checkboxes nested four deep in configuration dialogs. But Unix troubleshooting involves poorly documented application changes, path and permission trip-ups, and dependency hell spanning kernel, utilities, and the million micro-layer tools that connect it all. I don't know which I prefer, and that's weird to me.

I haven't gathered enough data yet to tell whether I prefer phpMyAdmin to SQL Server Management Studio, although a few inherent advantages of desktop-based apps over web apps might prevail here (see the last few paragraphs of my boss's lament).

Pop quiz: does the CREATE TABLE query that makes a table with a composite primary key (a tuple in this case) include the crucial word COMPOSITE in it anywhere? The answer is no! In case you're flipping through Ben Forta's SAMS book Teach Yourself SQL in 10 Minutes, Second Edition, you might find this useful:

	order_num	INTEGER		NOT NULL References Orders(order_num),
	order_item	INTEGER		NOT NULL,
	prod_id		CHAR(10)	NOT NULL References Products(prod_id),
	quantity	INTEGER		NOT NULL,
	item_price	MONEY	NOT NULL
PRIMARY KEY (order_num, order_item)

That might only work in SQL Server Management Studio, though.

I use various applications that call themselves "managers." SQL Server Management Studio, Adobe Download Manager, Mozilla's Profile Manager, what have you. They aggregate and maintain functionality and they're useful. But their names make it sound as though "managing" software is just a matter of checkboxes in the here and now, and not messy strategizing towards an unseeable horizon.

Filed under:

(1) : Decision Theories: Avoiding Projects Pursued By Morons 101:

There is much made by people who long for the days of their fourth form debating society about the fallacy of "argumentum ad hominem". There is, as I have mentioned in the past, no fancy Latin term for the fallacy of "giving known liars the benefit of the doubt", but it is in my view a much greater source of avoidable error in the world. Audit is meant to protect us from this, which is why audit is so important.

Avoiding hiring morons:

If the basic concepts aren't so easy that you don't even have to think about them, you're not going to get the big concepts....

You see, if you can't whiz through the easy stuff at 100 m.p.h., you're never gonna get the advanced stuff.

Filed under:

: In The Application Of My Seat To A Yoga Mat: Once upon a time, my brother-in-law-in-law wrote a bit about working out, Daylight Savings Time, doing stuff alone, and same-sex marriage. John's an interesting guy, and I find all of those topics worth exploring, but right now fitness weighs heavy on my mind.

My sedentary lifestyle and love of candy and Leonard's food have caught up with me, so now I'm actively working to increase my fitness and stamina and decrease the amount of room and mass that I take up. Both my parents have diabetes; I've started thinking long-term.

I started a TiVo Season Pass to a show on Lifetime, Denise Austin's Daily Workout. Denise Austin is a Mr. Rogers-style workout coach. At least two other people have blogged about the humorous incongruity between her sweet, friendly encouragement and the pain of working out. But any personal or impersonal trainer will evince that sort of thing. Two things that I find weird about Austin:

  1. She publicly and strongly supports George W. Bush, which makes me wonder about the science she spouts about metabolism, calories, etc. Does she think human-caused global warming is some unproven hypothesis?
  2. She was born in 1957, yet looks younger than I do. Not just her body, but her face looks about twenty years old.

But she doesn't creep me out, and I like the workouts.

Food, sex, money, the body: all these fraught topics disappear if I wholly involve myself in something. This works even if the activity centers on one of those topics. If I let the milquetoast Daily Workout electronica energize me and get my kicks higher and higher, I can escape. As I get better at gaming my body, I hope exercise escapism approaches the quality of literature escapism and comedy escapism.

I have been daniel.u ("I feel like my body is a station wagon in which I drive my brain around...") and now I'm stopping. Once I get the hang of remembering that I'm a physical organism, I'll incrementally improve at living consciously in my body, but right now it's triage. Get up and moving every day. Stop eating tons of starch. Stop eating free candy at work. (Now that I haven't had candy at work for weeks, sometimes I crave it, but sometimes I can't imagine eating handfuls every day, as some coworkers do, and as I used to.)

Perfect is the enemy of good, or done; half a loaf is better than none; doing something, for me, here, is better than doing nothing. I haven't joined the rapid prototyping cult, but I understand them better now.

Filed under:

: Marissa Mayer & I Both Use Pine: Over the past week I've been to three different tech-related meetsup. I went to an EFF-NYC group, I helped host the Fog Creek open house, and I visited the Joel On Software discussion forum meetup in lieu of my traditional Saturday night SKP visit. It'll be a good yield if I get two lasting friends out of the whole trilogy. Today I played the hermit, rereading America: The Book and bits of Jane Eyre in between working on my column and playing Tetris with my husband.

I've spent half a year with Fog Creek now, and I know its strengths and weaknesses almost as well as I know my own. I've just downloaded a bunch of Audiofile songs and the music makes me pensive. I'm wondering what it'll take for me to become an IT leader with soul and cred.

Do I have to be a tall blue-eyed blonde with patents in artificial intelligence? Is it that or Fiorinadom? Is it possible to feel like a completely lost pioneer and a cliché sellout at the same time? That sort of thing.

By the way, the Joel on Software jobs board has been hopping lately, and my boss has been blogging at unusually high volume.

Anyway, back to my columns. One is about times I've been truly happy. I think the other is about practice, craftsmanship, and the tradeoffs one makes to live a satisfying life. But I'm not sure yet.

Filed under:

: And Hanging On The Car Door Handle Was...A NetNanny!: Want to hear a horror story about control freak managers?

...The engineers were placed out of the loop regarding what was happening in the standards committee and when they finally agreed on a standard, our hardware could not support it....
Filed under:

: The Customer Is Always The Customer: Sometimes I wish I could defend "Keep it Simple, Stupid" with flair and confidence to people who think they need things that they probably don't. Folks who say "the customer is always right" have almost never worked retail. 99% of the customers are right; the 1% that are incandescently wrong bat off all attempts at reasonableness.

How do you kindly tell a prospective customer, "You are looking for something that our product does not and will not do"? It helps if you weren't trying to sell your product in the first place. Christopher Petrilli, a user of the open-source bugtracker Trac, writes about its ease of use and consequent design tradeoffs.

Honestly, if you can't trust your developers to set the box on a ticket to the right setting and need a nanny to do this for you, then you have problems infinately worse than lack of "workflow".....

Just my two cents, but if this is your "deciding factor," then I think you need to re-think your evaluation priorities......

Again, Trac isn't all-things-to-all-people, and so if you absosmurfly must have a formal workflow system, then I suspect you're going to need to look elsewhere.

Basically, I have been doing corporate customer service long enough that I find clear and straightforward "We won't do that and your premises are wrong" answers extraordinarily refreshing. I'm still trying to figure out why the Trac and PuTTY examples feel fresh and the 37 Signals "It Just Doesn't Matter" post feels grating and arrogant.

Filed under:

: No One Has a Calling Anymore, Just A Core Competence: All this time I thought I was a multiply-layered intersecting matrix of identities, and all this time I was actually a seven-word elevator pitch.

Filed under:

: Does Anyone (Who Writes This Blog) Have Anything Worth Saying Anymore?: Leonard and I were reading a really interesting comments thread comparing the advantages of tech publishing models in the middle of last week. Against all odds, it stayed almost entirely informative, polite, and well-written. Then:

God, it's all such a bunch of s***. It's hard to believe that anyone is buying stuff from either self-publishing or the mainstream press. The tech world, and the literature world has become so faddish.

Does anyone have anything worth saying anymore?

I'm trying to learn to deal with geeks. I thought they were like my friends, Zack and Seth and Leonard and Joe and Eric and Devin and Zed and Brendan and Riana and too many names to reel off. And the people at Fog Creek are also of this type and I can communicate with them. But somehow I selected for something -- compassion? well-roundedness? a lack of arrogance? -- and now I have to learn how to talk and work with these people, this other species.

The geeks I'm running into socially here are almost all white guys, probably wealthier than me, usually older than me, and they treat feelings and uncertainty as irrelevant distractions. I believe that there's a difference between not caring what people think and not caring how people feel; this distinction eludes many of my new acquaintances. And forget about showing vulnerability! Their neat and easy distinction between their ideas and their selves means that I'm never talking to them, can never affect them one way or another. For all I know, they were born on third base (hitting the lottery in the Punnet Square of machine intelligence) and think they hit a triple. And I've gotten halfway through Glen's Leading Geeks and Duncan's The Career Programmer: Guerilla Tactics for an Imperfect World and they make me want to run for the hills. Am I choosing to spend the rest of my life working with misanthropic, nitpicking jerks?

Part of me wants to be productive and useful, to engage with the Other. After all, isn't this what I have to do? I'll have to work with this personality type for the rest of my life; shouldn't I resign myself and acclimate? And part of me is yelling, loud enough that it interferes, "God, it's all such a bunch of s***!"

Rachel has an awesome career that I could imagine having someday. But I would still have to show compassion for and empathize with people who never return the favor. The more I can understand and work with them, the more like them I become, and I want to keep that part of me that doesn't act like a machine intact. Irrational, non-adversarial, respectful, compassionate stuff is important.

Their arguments keep ringing in my head, the way Ayn Rand's used to, telling me to come over to this utopian paradise where nothing can ever hurt you. After all, they've already won. They set the terms for discourse in the places where I'm going to work if I keep up the career I've chosen. And they think they understand all my arguments and have already proven me wrong.

Or are you so flummoxed and confused and crazy that you decided that what they did made it OK for you to forget the handbook? They're evil, so ... so what? So you get to be evil? Well, of course you get to be evil, but then you're evil. Is that how you envisioned it turning out?

More Jon Carroll, since I'm in that mood:

I mean, render unto me a break. If your family feels so threatened by my family that you think you have to organize a boycott of a car company, then your family has problems my family can do nothing to solve.

I've been reading Jon Carroll archives and lists of April Fool's Day Hoaxes and they make me feel better because they make me laugh. I prefer laughing to arguing with the voices in my head. I miss my friends, I miss San Francisco, I miss the time before I saw mice in my apartments, I miss not caring whether admissions people at major universities saw what I wrote on my blog, I miss thinking that I could get along equally well with suits and geeks. Now I think I get along equally badly with suits and geeks, and that if I want to be a good interface between those two sides, I have to change into someone I don't think I want to be. I feel as though my self is in danger.

I'd say that it'll all be better in the morning, but that's what I thought last night, and this is the morning. But eating might help.

Filed under:


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