Categories: sumana | Management and Leadership
# 03 Jul 2021, 04:45PM: Researching The Leadership Gap for Legacy Projects:
I've given a lot of conference talks recently. As part of the PyCon US Maintainers' Summit in May, I delivered an eight-minute talk, "Researching the leadership gap for legacy projects". The video is now available, and here's the written version (I did not use slides).
- Introducing the question/problem
- A little more about the problem I see
- Tooling hypothesis
- Corporate involvement hypothesis (hypotheses)
- New problems hypothesis
- Values and culture hypothesis
- How would we check?
Hi! I'm Sumana Harihareswara of Changeset Consulting and I'm not using any slides today, so you're free to take a few minutes to stretch, fold some laundry, what have you.
Introducing the question/problem
We have a pipeline for getting folks with coding skills to start or contribute to open source projects. That's great and I'm glad.
But I'm pretty sure we don't have a pipeline to recruit or grow contributors with leadership and management skills. A maintainer of a widely-used project *is* a manager, but since skilled managers are scarce in open source, we're seeing important projects stumble, or even wither, for lack of managerial work. (At least, this is what I've seen, and if you are seeing something to the contrary, I want to hear about it.) And I think this is a factor in the open source sustainability problem.
Knowing why this is happening can help us fix it. So in this talk I'll share a few hypotheses: one about the tooling we build and use, one about the effects of corporate involvement, one about changes in the problems we're trying to address, and one about values and culture. And I'll talk about how we would check whether any of these are true. I hope that considering this question will aid your efforts in focusing time and energy on things that will make a difference to project sustainability.
A little more about the problem I see
Founders start projects but are unprepared for the managerial demands of maintaining things that other people depend on. And, when legacy projects stagnate, contributors don't know how to take them over and stabilize them by solving common strategic, team, communication, workflow, and financial problems. Since they don't know how to rehab existing projects, individuals and orgs fork or start new ones, exacerbating fragmentation headaches.
So what hypotheses do we have?
Here's one. It used to be that, if you were going to run an open source project, you had to make the tooling platform yourself. You had to set up and administer, and maybe even build, your own bug tracker, source code repository, wiki, documentation site, and tarball release repository. Now these are hosted services -- GitHub, Read the Docs, PyPI. That means that it's easier to start a project, but that also means it's easier to start a project without learning a lot about the value and capabilities of these platforms along the way. And then project founders are less equipped to use those things well.
Corporate involvement hypothesis (hypotheses)
Here's another: it changes things when companies get more and more involved in open source, or hire people from open source. Maybe big companies hire the people who have managerial skills, and sometimes take them out of open source work entirely, and leave behind the ones who don't. Or maybe open source would be failing worse without corporate involvement, and corporate engagement is sort of subsidizing the poor management that we would otherwise see.
New problems hypothesis
Here's another: what got us here won't get us there. We're trying to address new or unsolved or undersolved problems and areas in open source -- distributed and cloud computing, getting telemetry while protecting user privacy, user experience design that can stand up to the best that industry can offer, diversity, equity, and inclusion, and so on. So, in general, open source contributors have grown a certain median level of leadership skill, but we're seeing cracks in the infrastructure because of the new loads they are trying to handle.
Values and culture hypothesis
Here's another: Let's talk about our culture and values, and how that affects contributor retention and promotion. We in open source recognize and promote people for the code they write, but we're bad at recognizing and valuing people for the managerial contributions they make -- we treat glue work https://noidea.dog/glue as invisible. So we don't attract or retain people with managerial skills or with the interest in growing in that direction.
And I'd like to thank Amye Scavarda for some thoughts about some of these hypotheses.
How would we check?
So. How would we check whether any of these are right? A few thoughts. We could talk with the scholars who were funded by the Ford and Sloan Foundation grants on critical digital infrastructure to get their thoughts. We could work with the CHAOSS people, the open source metrics working group, to construct a means to quantitatively measure maintainership actions happening within a project, and find out what other attributes it correlates with -- like whether or not those particular projects, or the domain areas they're in, were particularly influenced by companies. We could look for conversations from 15 years ago to check what our forebearers were saying, whether they thought this was likely to be a problem. We could try to offer explicit skills learning opportunities to contributors, to see whether people are interested, and whether we can find ways to retain the people who take those offers as open source maintainers.
My gut says that the source of the problem is a mix of the corporate involvement and values and culture hypotheses. So that's the basis I'm working from. I am working on a book outlining and teaching the skills open source software maintainers need, and teaching these skills to contributors who have never managed public-facing projects before. It'll be a textbook or a self-help guide for new and current maintainers of existing projects (what I call "brownfield projects", as opposed to "greenfield") and will focus on teaching specific project management skills (such as initial project audit, grantwriting, bug triage, and meeting facilitation) in the context of open source. If you go to changeset.nyc, under "resources" you'll find a free sample.
But let's talk during the Q&A session on Thursday. Which, if any, of these hypotheses ring true to you, and how could someone check whether you're right?
# 29 Apr 2021, 04:07PM: Thinking About Safety And Competing Access Needs:
I don't have much to say about this but this piece ("safe spaces and competing access needs") and this discussion ("Safe" isn't a monolith.) have been rolling around in my head a lot, and I thought you might like to think about them too. Especially if you have responsibility for any shared physical or virtual group or venue that has a Code of Conduct, and especially if anyone in it has ever suggested that particular words or topics ought to be off-limits.
# 09 Apr 2021, 01:11PM: If You Call Me A Thought Leader For This Post I Will Give You A Stern Look:
In scifi/fantasy fandom there's this phrase, "Big Name Fan". This is someone who is well-known, influential, for the fannish things they say and do and make. The idea is that a BNF is a minor celebrity -- not at the television-interviews level, but still, within their Internet and convention circles, someone who gathers a crowd, and whose tossed-off words have disproportionate power to help or hurt others.
The chunk of fandom I'm thinking of is, mostly, women. We're socialized to not admit when we have power, and to shut up and use it to serve others. Joanna Russ wrote about this dynamic in "Power and Helplessness in the Women’s Movement"; fan Hope reiterated that expectation in "Nobody Ever Admits They're a BNF", advising Big Name Fans that they get to benefit from feelings of belonging but "You are not allowed to have hurt feelings, you are not allowed to argue with someone, and you absolutely are not allowed to have an opinion." I think the only/first time I've found out that I've been called a BNF, it was in the context of someone criticizing my too-abrupt comments in a Dreamwidth thread; they were disappointed, taken aback, at such a BNF acting in this way.
Given that it's considered arrogant to call oneself a BNF, at least in public, perhaps you can infer how difficult it then is for a person to honestly and transparently reckon with the concomitant opportunities and constraints.
And perhaps you can draw a line from this dynamic to ones in the developer relations industry, or in large collaborative volunteer groups such as major open source projects, etc. If you have an explicit role such as "conference chair" or "professor" or "maintainer" then you know whether you inhabit it or not, you can straightforwardly mention that you hold it, and you and your peers can come up with norms for the special powers and responsibilities that come with it. But absent that? As far as I am aware you do not get a how-to book and access to an all-celebrities group chat upon achieving some number of Twitter followers. A person who has gradually accreted influence must notice that they have more intangible influence than most of the people they talk and listen to, and -- through reflection, study, and private conversation -- develop their own guidelines for how to use that influence.
But: there's how you act, and then there's how everyone else acts toward you. No matter whether or not they get some explicit roles to help everyone understand these kinds of expectations, I think -- at least in the bit of US society that I'm used to, where we have strong egalitarian ideals -- we don't help newly powerful people get used to all those social epiphenomena that will now start brushing against them. Envy, intimidation, and so on. Maybe there are now influencer finishing schools that include "you are now the object of other people's projections and their parasocial interactions with you will get very weird" in their curriculum.
I have counterproductive feelings and habits in my head that relate to this whole issue, around envy, martyrdom, etc. As with the stuff I mentioned earlier this week in "Paralipsis", this blog isn't the right place to work through those things. This week I'm particularly grateful to friends of mine with whom I can talk candidly about this stuff. And if you and I are friends, perhaps we can talk about it too.
# (1) 22 Mar 2021, 09:09PM: A Spec For A Sandboxed Open Source Project Environment:
I'm writing a book on maintaining legacy open source projects to help teach people vital skills. Right now, as far as I know, there's no textbook or course you can work through to learn skills like assessing an open source project systematically, triaging bugs, noticing quiet-but-promising contributors to promote, improving code review processes, writing a grant proposal, and finding your successors. Or, more accurately, there are courses and guides that cover different software leadership areas, but there's nothing that covers the whole toolbox.
When I'm teaching skills, I want to give learners exercises they can use to develop and practice those skills. And if I turn the book into a course, I'll want to be able to assign those exercises and review their homework. So I started thinking: how nice it would be if I could snapshot or composite together a sample legacy FLOSS project, complete with messy old issues, docs, and chat and list archives, and replicate it in self-serve sandbox instances for exercises!
I've been thinking about this for a while. Today I wrote up a spec. I don't know what to call it - "Maintainer Sandbox", "Snowglobe Factory", and "Diorama" all sound good. The spec below assumes that I'd be leading a cohort of learners through a semisynchronous online course; it would work fine for an in-person class as well, but I'd have to adapt the access levels part for a completely self-paced and self-driven course.
As instructor, I would create a snapshot of a sample open source project (comprising materials listed below). The hosting platform would replicate it in self-serve instances, usable over the web, for user exercises. Upon signing up for a course, a user would get access to a freshly provisioned instance, complete with project history.
Materials: Each instance would include the following artifacts, all browseable and searchable via the web browser:
- Bugtracker-type artifacts and history that would generally be available as part of a GitLab or GitHub project: a git repository for code history, past and present issues and patches/pull requests/merge requests (complete with tags/labels, milestones, assignees, and similar metadata), past release announcements, and a wiki
- Project documentation and overview information for users and for developers, as would generally be available on a project's website (even if documentation source is available in the git repository, the snapshot we provide should include the docs as rendered into HTML)
- Archives of the project's mailing lists, as would generally be available as a Mailman, Majordomo, or similar instance, browseable and searchable via a web interface like this web view of python-dev (a Mailman 3 list)
Archives of the project's chat conversations, using a public Zulip chat history like this public archive of Rust's Zulip chat or a browseable history of Internet Relay Chat conversations via a web interface like this web view of Freenode's #pypa logs
(Olivier Lafleur conversed with me on Twitter about how to do some portion of this using GitLab. Also, the Perceval project may be a good tool to consider for mailing list and chat archives.)
Access privileges: The learner would not only interact with the example project materials as a reader but also as a participant, moving through the three access levels described below. The instructor would be able to view a learner's instance, with administrator (Level 3) access, to assess the learner's actions.
Level 1: The learner starts with the same user privileges that a new user would ordinarily have -- they can read all the public mailing lists, chat histories, wiki, and bugtracker items, and file bugs.
Level 2: The instructor can promote the learner to the second access level, at which point they can (for instance) triage, label, and close bugs and pull requests/patches, edit the wiki, and post to public mailing lists.
- Level 3: The instructor can promote the learner to the third (administrative) access level, at which point they can (for instance) browse and post to private mailing lists and chat channels, and use maintainer powers on the git repository (such as merging pull requests/patches).
Authentication: I imagine that dealing with authentication within the application could get sticky. My preferred approach:
- As a signed-in platform user, the learner is automatically logged in to all the web applications within the instance, and cannot log out.
- It is not possible to view an instance unless you are either the learner or instructor associated with that instance.
Multi-user access: Ideally, it would also be possible for an instructor to expand access so that a project can have multiple users (in other words, give Learner A access to Learner B's project instance), so that learners can engage in peer learning and group exercises. However, I expect that would lead to a much larger range of headaches, including Code of Conduct problems in interactions between learners, so -- in earlier versions of this tool -- I am fine with not having this functionality, and instead advising pairs and small groups to use screen sharing for group exercises.
End of life: At the end of the course, each instance would turn read-only for two weeks (to allow the learner to make notes, and to make local copies of any work they had done), and then the platform would delete the instance.
Thoughts? In particular, if you know of software that already does more than half of what I want, I'd like to know about it.
# 16 Mar 2021, 08:18PM: MozFest 2021 Followup: Apply for Grants To Fund Open Source Work:
This session was in two parts:
- a fifteen-minute video (a remix of the session I delivered at PyOhio, with five additional minutes of material)
- a one-hour discussion
The additional material in the MozFest video
, rough script
- a shout-out to the OpenHumans grant opportunity
- more hypothetical budgeting details: Seven months of working full-time is probably enough time for a skilled Python developer to port a command-line tool for geology researchers from FORTRAN to Python. Or, if you split that money between a user experience researcher and a technical writer, again at $150 per hour, then they could work together for three and a half months, which is probably enough time to interview a bunch of your users, make a really detailed report on user needs to help your developers prioritize your roadmap, overhaul all of your documentation, and overhaul a lot of your error messages.
- an overview of the kinds of information most funders want in grant proposals:
- basic contact details, including the person or organization that will receive the money
- a few paragraphs about the task you want to perform
- the amount you're asking for, and a short description of what you'll spend it on
- who uses your software? have some statistics here - download numbers, users on the mailing list, etc. -- but also this is where you talk about specific important or prestigious users and downstreams.
- what goals will this accomplish? how it will make the world a better place? and why do people need this? why is it important?
- what is your plan for how you'll do it -- how will you use this money? what's your proposed schedule? try to break things down so no chunk of work takes longer than a month; if your project stretches out over 6 months or more, try to break that up into 3 or more milestones, each of which is a few months' worth of work, to help the reviewer think about what you might get done if the project goes over schedule and you run out of budget
- does this project currently get any other regular income?
(Since funders are mostly asking the same questions, you can take a rejected proposal and lightly rewrite it to submit to another funder. Kind of like how I gave a version of this talk in 2020, then added some more material to share at MozFest in 2021.)
The discussion was lively and varied. We talked about several topics and shared resources, and wished there were a thorough aggregator of funding opportunities for open source work, bigger than the one that the PSF's Project Funding Working Group has put together.
Some funding opportunities people brought up:
And we discussed the question "how do you get a community going and solicit money when you don't have anything to show yet?" and the fear that people will steal one's ideas, and the problem of answering funders who ask you "how will you sustain this project after the funding ends?"
Some other resources people mentioned:
Thanks to everyone who watched or participated!
# 15 Mar 2021, 11:21AM: Rick Steves, Underappreciated:
Jacob Kaplan-Moss suggested I write this up so here you go!
This weekend I listened to the "How I Built This" interview with entrepreneur Rick Steves.
You may have heard of Rick Steves and thought he was just another travel guidebook writer. He's not! He's a marijuana legalization advocate and serves on the board of director of NORML. He loves helping Americans travel outside our own country because he thinks US folks need to travel internationally more and widen our perspectives and reduce our American exceptionalism. His Lutheranism leads him to emphasize the equal importance of every single person on Earth; if you find 1999 and 2000 editions of his guidebooks you'll find an appendix about the need for a Jubilee Year to forgive the debts of developing countries. He "devised a scheme where I could put my retirement savings not into a bank to get interest, but into cheap apartments to house struggling neighbors" and encouraged fellow rich people to do the same.
He's an inspiration to me as an entrepreneur and as a teacher. He started off teaching a class on cheap European travel -- because no one else was doing it! -- and turned that lecture into his first book. Hearing that story reminded me that the book I'm writing will be a lot better if I test it out as a curriculum as I write it. So now I'm thinking about how to do that with real learners.
And I want to be an entrepreneur who, like Fred Rogers, like Anant Pai, like David Neeleman, like Rick Steves, found a need and filled it, while making money, employing people, and making a little slice of the world easier.
# 27 Jan 2021, 08:01AM: Gaps in Existing Guidance on Open Source & Software Management:
I'm working on a book proposal for the full-length book version of Getting Unstuck: Advice for Open Source Projects (38-page sampler available now for free download when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).)
In the process, I've developed a list of existing books and online resources on open source maintainership and on software management, and I've thought more about why general software management advice -- which usually assumes you and your colleagues all work for the same company or other organization -- doesn't address most open source maintainers' needs.
Writing a book proposal: kind of necessary, kind of a drag
In nonfiction book publishing, a book proposal is the way you say to a publisher, "I think it would be a good deal for both of us if you published this book I'm writing." For example, No Starch Press would like a summary, an outline, and descriptions of the audience, the competition, the market, and the author. All the publishers I'm considering want to know those things, and some also want to know the schedule for completion, which other books from that publisher cover related or similar topics, the authorial approach I'll use, what keywords readers would search for to find this book, and more.
I might not go with a traditional publisher; I might self-publish, either all at once or in stages, such as via my email newsletter. But writing this proposal gives me more options and makes me think through what I'm planning to do. Still, it can be a drag to spend time on persuading other people that something is a good idea instead of executing on the idea itself, and it is a specific drag for me to spend time writing something that very few people will see.
The most immediately-useful-to-others part is probably the literature review, the overview of books and similar resources that are in any way comparable. Thus:
So here's my competition. I don't mean to disrespect any of these works or their authors, just to clearly state what they do and what they don't do (and thus why there is still a need for my book).
I hired Audrey Eschright to start this and then I continued it myself -- thanks, Audrey! I know this is incomplete and I'll remember another thing three hours after I post this (I may edit to add things), but I figure it might be useful to folks looking for books and web curricula about open source, project management, maintaining legacy systems, and so on.
Open source & related
Book and online resource: Producing Open Source Software: How to Run a Successful Free Software Project by Karl Fogel, 9780596007591, published by O'Reilly, 2005 (web version is second edition, revised 2017)
Audience: FLOSS newbies, programmers and managers, new project contributors and maintainers
Covers/teaches: FLOSS culture, communication tools and techniques, project management, governance, structured collaboration
Good: Friendly, detailed, aimed at software professionals at least as much as side-project folks
Missing/needs (or, not designed to cover): Mostly about greenfield projects; does not cover how to come into an existing project and lead it (Fogel has thus encouraged my own project as a kind of sequel to his); limited discussion of managing problem contributors, bug triage, and planning roadmap; very little/no discussion of budgeting, grant proposals, and succession planning; somewhat out-of-date regarding discussing modern tooling
Book: Forge Your Future with Open Source by VM Brasseur, 9781680503012, published by Pragmatic Bookshelf, 2018
Audience: FLOSS newbies/new contributors (professional and volunteer), programmers and other relevant skill sets
Covers/teaches: FLOSS culture, common tools and practices, open-sourcing a personal project
Good: Reasonable sequence; clearly written; covers major gotchas new contributors will run into
Missing/needs (or, not designed to cover): Maintainer skills, working with a legacy project
Book: Working in Public: The Making and Maintenance of Open Source Software by Nadia Eghbal, 0578675862, published by Stripe Press, 2020
Audience: Technologists, managers, and interested bystanders such as sociologists and economists
Covers/teaches: General principles regarding FLOSS sustainability and dynamics
Good: “An anthropological dive into the stories of real developers” with some useful explanations of some dynamics in open source projects (such as the categories of "toy, club, federation, stadium," based on the ratios of users and contributors and user growth and contributor growth)
Missing/needs (or, not designed to cover): Is inaccurate in ways that accumulate page by page. This surprised me badly, especially since her Roads and Bridges report was so helpful. My copy of Working in Public has corrections and rejoinders from me in the margins of about every fourth page. I need to write a more thorough review but, in short, Eghbal's choices to ignore all projects that don't use GitHub, and all contribution types other than code commits, and all of the effects of venture capital on the economics of open source, and the roles governments can play in funding digital infrastructure, constrict the analysis and recommendations towards a disappointing conclusion that will not help most of the infrastructural open source projects (and their maintainers) I know and work with. Also, it does not provide practical advice for maintainers (such as instructions and exercises) on dealing with specific issues to rescue legacy projects. (Updated this summary in July 2021.)
Online resource: Mozilla Open Leadership Training Series (online curriculum), Mozilla contributors, started in 2016 and updated since then
Audience: “Anyone starting up or leading open projects– project leads, collaborators, or small groups of co-leaders responsible for project success and growth”
Covers/teaches: Communication, community-building, using GitHub, mentoring, project maintenance, organizing events
Good: Multiple kinds of content, exercises to use, explains FOSS collaboration without requiring a technical background
Missing/needs (or, not designed to cover): Budgeting, working with a legacy project instead of starting a new project
[Edited 2021-02-05 to add] Online Resource: TODO Group guides (online), various authors, started in 2019
Audience: engineering executives at large organizations
Skills taught: participating in open source communities, building leadership in a FLOSS project and improving open source development impact, and related topics
Covers/teaches: General overview of how to start participating in open source projects and grow into leadership; realistic and business-focused understanding that contributing to existing projects often has greater return on investment than starting new ones; specific tool recommendations
Missing/needs (or, not designed to cover): Detailed instructions on providing coordination and maintainership; assumes incoming participants have an architectural/feature agenda (rather than just wanting more frequent releases); lack of detailed examples, exercises; assumes reader already has basic project management skills (since it is aimed at executives rather than individual contributors)
[Edited 2021-07-13 to add] Online Resources: "Growing Open Source Projects with a Stable Foundation" by Martin Michlmayr, and the accompanying research report on "the operations and challenges FOSS foundations face", published 2021-04-28
Audience: Practitioners and funders in open source software
Skills taught: "This primer covers non-technical aspects that the majority of projects will have to consider at some point. It also explains how FOSS foundations can help projects grow and succeed." Like a shorter, high-level and up-to-date version of Karl Fogel's Producing Open Source Software, focusing on governance and related systems and processes.
Covers/teaches: FLOSS governance approaches, legal and financial issues, structures to accommodate and encourage project team growth
Good: Very recent, has lots of examples of how existing organizations address certain kinds of needs
Missing/needs (or, not designed to cover): examples, techniques, and exercises for learning the skills to implement Michlmayr's suggestions
[Edited 2021-02-10 to add] Online Resource: The Open Source Way (online), various authors, first edition 2009, second edition 2020
Audience: People, with varying levels of experience participating in open source projects, who want to participate in and lead them
Skills taught: Participating in open source communities, building leadership in a FLOSS project and improving open source development impact, and related topics
Covers/teaches: General overview of how to start participating in open source projects and improve their user and participant bases, and measure one's success; realistic advice based on experience
Missing/needs (or, not designed to cover): Mostly about greenfield projects; does not cover how to come into an existing project and lead it; limited discussion of managing problem contributors, bug triage, and planning roadmap; very little/no discussion of budgeting, grant proposals, and succession planning
Online resource: Opensource.guide (online curriculum), GitHub team and other contributors, started in 2016
Audience: GitHub users, maintainers of new projects, FLOSS newbies, people outside existing FLOSS organizations, programmers
Covers/teaches: FOSS culture, technical management, outreach, inclusive practices, leadership skills
Good: Overview of many important aspects of running an open source project
Missing/needs (or, not designed to cover): How to turn around a legacy project, especially when starting as a non-maintainer contributor; non-GitHub forges (resource is entirely GitHub-specific)
Online resource: Google Summer of Code Mentor Guide , multiple authors, started in 2009 and updated since then
Audience: FOSS project mentors
Covers/teaches: Mentoring, communication, FOSS cultural knowledge, commit/patch management
Good: Detailed guidelines for mentor/student interaction and evaluating progress
Missing/needs (or, not designed to cover): Organization could be improved; indicates but doesn’t address the issue of project culture not being friendly to newcomers aside from how you guide the student through it; no guidance for how to run a project overall, since it concentrates on just the act of mentoring an intern.
Online resource: The Field Guide to Open Source in the Newsroom, OpenNews contributors (including me, Sumana Harihareswara), started in 2016 and updated since then
Audience: Journalists and news organizations
Covers/teaches: FOSS culture, tech skills, documentation, community management, leadership transitions, starting a new project as open source or opening the source code to an existing project
Good: “Handoffs and Sunsets” section, good examination of the beginning and ends of projects
Missing/needs (or, not designed to cover): Is still unfinished and lacks thorough examples. Does not cover the case of coming into and reviving an existing open source project, and has little to no advice on project management
Book: The Art of Community: Building the New Age of Participation, by Jono Bacon, 9781449312060, published by O'Reilly, 2012
Audience: Novice contributors/leaders/community managers for open source software and open culture organizations (assumption that reader does not already know the basics of how open source contribution works)
Covers/teaches: Making a mission statement and strategic plan, introducing process, marketing, governance
Good: Specific advice on communication channels, writing skills, governance, conflict management, basic event planning, and marketing; anecdotes and lessons learned from many projects. Online component.
Missing/needs (or, not designed to cover): Is at least eight years out of date (example: Gobby and Identi.ca recommendations); assumes you can build new processes and communities from scratch, instead of helping people who are joining midstream, quirky writing style will put off some readers
Book: People Powered, by Jono Bacon, 9781400214884, published by HarperCollins Leadership, 2019
Audience: Executives at businesses
Covers/teaches: Initiating and exploiting user groups for products and services (not specific to open source software)
Good: Specific instructions on sequence and strategy for creating new user groups
Missing/needs (or, not designed to cover): No discussions of joining and co-maintaining existing open source projects; aimed at existing executives who are not yet open community contributors, not current open source contributors
(There are dozens of reasonably well-regarded books on software management in general, from classics like DeMarco & Lister's Peopleware to more recent works like the Fournier I mention below; most of them are only partially suitable for my target audience for the reasons I mention in "What doesn't get covered".)
Book: A Civic Technologist’s Practice Guide by Cyd Harrell, 978-1735286501, self-published, 2020
Audience: People who are doing, or want to do, civic technology -- developers, entrepreneurs, and people in related fields
Covers/teaches: How government tech works, choosing contribution and project types, ways to avoid common gotchas to make long-term change without burning out
Good: Distills a wealth of experience, clearly written, realistic, good sequencing
Missing/needs (or, not designed to cover): Has only a single section within a single chapter on “Open-source teams and assumptions”; generally assumes institutional funding
Book: Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones) by Marianne Bellotti, 9781718501188, forthcoming to be published by No Starch Press, March 2021
Audience: Managers within existing large organizations
Covers/teaches: “How to evaluate existing architecture, create upgrade plans, and handle communication structures.”
Good: Probably engagingly written based on Bellotti's other work; “team exercises and historical analyses of complex computer systems”
Missing/needs (or, not designed to cover): Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects such as volunteer-run open source projects
Book: The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change by Camille Fournier, 1491973897 , published by O'Reilly, 2017
Audience: Engineering managers within companies and similar organizations
Covers/teaches: Leadership, planning, decision-making, team culture, people management
Good: Coverage of common dysfunctions, good sequencing and clear writing; covers both line-level and senior leadership roles
Missing/needs (or, not designed to cover): Very little attention paid to open source dynamics; Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects such as volunteer-run open source projects
Book: Making Things Happen: Mastering Project Management by Scott Berkun, 9780596517717, published by O'Reilly, 2008 (formerly “The Art of Project Management”)
Audience: Project managers at large organizations
Covers/teaches: Leadership, planning, decision-making
Good: Detailed, funny, includes guidance on communication methods (such as meetings and emails) as well as discussion questions
Missing/needs (or, not designed to cover): Assumes that the project is housed within a single organization, and is thus mostly inapplicable to multi-stakeholder projects; assumes in-person collaboration and does not accommodate open source project approaches
If I've made any substantial errors in my descriptions of these books and websites, please let me know. And if you think I've missed a work, if you think the book I'm working on substantially overlaps with prior work that I have not mentioned, please tell me. I don't want to waste anyone's time and I wish to minimize duplication of effort.
What doesn't get covered
There are lots of guides to starting open source projects, but overall they do not address the needs of a new maintainer of a legacy project. As Marco Rogers recently observed regarding code-related tutorials: "there is very little content that is appropriately labeled as intermediate to advanced....A lot of content is pointed towards either newbies or people doing greenfield work."
And there are many books about managing software projects, including complex infrastructural and legacy projects. They generally assume you're making proprietary software, and so (except for works like Bacon's) they don't account for the benefits of working in the open, the possibility of getting gratis contributions from users, open source strategy for the enterprise, and so on.
But also -- more crucially for a project management book -- on the whole they assume that all contributors are paid staffers, usually of the same organization. This is a somewhat less obvious distinction so I'll discuss it at a bit more length.
The job of a project manager varies wildly depending on how much power you actually have to say no to things and change delivery deadlines, whether you have the power to hire and fire people, and whether the colleagues who work on your project are solely working on your project (or splitting their time among multiple projects). Much of the existing writing on software management assumes that you are working in a mostly-hierarchical environment bounded by a single organization, where someone has the power to hire and fire, there is a monetary budget you control or have to keep track of, and so on.
Certainly some orgs are more hierarchical than others and there exist some where you basically have to use persuasion if you want a change to happen. First, of course that dynamic privileges some people, and it's worth checking for -isms in who gets to just veto things for no reason and who doesn't. And second, even so, if you and the other people you are influencing are in the same org and are being paid by the same employer, you still have different cues and levers available to you. Here are some structural differences between managing a more cross-org or extra-institutional project and managing one where everyone is being paid by the same employer:
- If you send an email or assign an issue, they are more likely to feel pressure to actually read and answer it; at some point, if they absolutely never listen to or respond to stuff their colleague is saying, that may lead to repercussions in the rest of their job. Ditto for if you invite them to meetings, retreats, etc.
- It's much more possible to make systematic changes that then affect lots of projects/individual contributors through systematic incentive or environmental nudges that apply to ALL contributors, e.g., working with senior managers to make [activity] a factor in promotions, which then facilitates getting [activity] to happen in YOUR project(s).
- If your team is remote, it's somewhat easier to arrange an in-person retreat, because it's way easier to get and figure out budget, it's easier to figure out *whom to invite*, to *schedule* it, to deal with expenses and so on. This means you can have more and better high-bandwidth meetings to build trust and make complicated decisions.
- The existence of centralized IT that you (and individual contributors) probably don't have to run yourself, and that everyone already is accustomed to using, and forces that somewhat delay/prevent tool fragmentation, means that if you set up a project management dashboard or similar, it's easier to ensure that all your colleagues are getting reports from it, that it ties into their existing communication feeds, and so on.
- You likely can access a list of your colleagues and (in organizations that are not giant) you can find out a fair amount about them when a new one comes onboard in a role that you will interact with, and you can be alerted or find out when one leaves the org entirely.
- There is a more bounded, finite set of stakeholders for you to deal with (including whom you could possibly ask for more budget), and it's easier for you to know who your users are.
- If someone really does not want to obey the Code of Conduct, it can escalate to the personnel department and they may get fired.
Thus: my book
So I am continuing to work on the full-length book version of Getting Unstuck: Advice for Open Source Projects (38-page sampler available now for free download when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).)
Once I finish this proposal.
# 24 Jan 2021, 06:21PM: Outline and Links for "How To Get A Project Unstuck" LCA Talk:
Here's a brief outline, and relevant links, for the talk I'm about to give at Linux.Conf.Au: "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I am not presenting any slides.
My consultancy is Changeset Consulting.
- Gathering info and helping decisions:
Mailman (What was new in GNU Mailman 3.0, announcement of the Mailman 3.0 release)
- Gathering funding:
Video, transcript, and slides for my PyOhio talk on applying for grants to fund open source
"Problems and Strategies in Financing Voluntary Free Software Projects" by Benjamin Mako Hill
Autoconf (Case study: rejuvenating Autoconf; also see how my upcoming book is helping Autoconf's developers decide what to do next)
- Nudging, prioritizing, and communicating:
Pipenv (Pipenv case study)
A case study I didn't have time to discuss in this talk: Finishing the rearchitecture and deployment of PyPI.
The credibility and change sequence
This is the outline of my forthcoming book. My sampler ebook of Getting Unstuck: Advice For Open Source Projects, available for free download once you subscribe to my 1-10 times per year newsletter, includes that full outline. The basics:
- Settling in (doing routine tasks that do not require much trust)
- Taking charge (doing things that require trust but that the group has already agreed needs to happen)
- Making change (modifying and adding social, digital, financial, and legal infrastructure)
- Passing leadership over to successors and leaving
I may also refer here to "Software in Person", my article on how to make the most of synchronous developer events.
Why maintainers usually don't have these skills
Where maintainers come from, what we value and grow, and a lack of tools and practices to help learn and teach these skills.
Let's change that
Existing initiatives or resources to improve and teach these skills:
Ideas for further tools and practices to improve skills (this is where I mention possible improvements to GitHub's "saved replies" tool).
Thanks for watching and listening. I look forward to hearing your thoughts, so please contact me to let me know!
Edited Feb 5th to add: video is now up! And thanks to Nick Murphy, R. Fureigh, and Keffy R. M. Kehrli for being test audiences!
# 23 Jan 2021, 07:36AM: Advice From My Book Helps The Autoconf Project Assess Itself:
A few weeks ago, I released a sampler from my upcoming book on rejuvenating open source projects: Getting Unstuck: Advice for Open Source Projects. It's like a lengthy trailer in text form.
You can get this 38-page ebook for free when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).
And readers are already using what they learned in this book to help their open source projects level up. Zack Weinberg, who worked with me to start rejuvenating Autoconf, read the sampler and learned a lightweight framework for assessing a project. He immediately used it to assess the GNU Autotools:
Should development of the Autotools continue? If they are to continue, we need to find people who have the time and the inclination (and perhaps also the funding) to maintain them steadily, rather than in six-month release sprints every eight years. We also need a proper roadmap for where further development should take these projects. As a starting point for the conversation about whether the projects should continue, and what the roadmap should be, I was inspired by Sumana's book in progress on open source project management (sample chapters are available from her website) to write up a "strengths, weaknesses, opportunities, and threats" analysis of Autotools.
This inventory can help us figure out how to build on new opportunities, using the Autotools' substantial strengths, and where to invest to guard against threats and shore up current weaknesses.
Zack sent his writeup to the Autoconf mailing list
where it's spurred a productive discussion about project architecture and inter-project coordination -- see his followup message
about particular tasks that, if funded, could address concerns that he raised. These concrete proposals will make it easier to seek specific grants or directed donations from funders -- companies, foundations, etc.
The sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:
- Introduction (including my controversial? "Basic assumptions about open source and the tech industries")
- Conducting a SWOT analysis (assessing a project's strengths, weaknesses, opportunities, and threats, with example analysis of the pip project)
- How to start thinking about budgets and money (including two exercises)
- Teaching and including unskilled volunteers (with twelve specific tactics)
- An outline of the full forthcoming book
Get the sampler for free when you subscribe to Changeset's email newsletter (1-10 updates per year).
And, in about a day and a half, I'll speak for the first time at Linux.Conf.Au, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". I'll tell some stories of projects I helped get unstuck, and share more material from the forthcoming book. Ticket sales are now open for LCA (which is, of course, a virtual convention). Buy a ticket if you'd like to see my talk live and participate in questions-and-answers!
# 01 Jan 2021, 04:50PM: New Free Ebook Sampler from "Getting Unstuck: Advice for Open Source Projects":
I've written and released a sampler from my upcoming book on rejuvenating open source projects: Getting Unstuck: Advice for Open Source Projects. It's like a lengthy trailer in text form.
You can get this 38-page ebook for free when you subscribe to Changeset Consulting's email newsletter (1-10 updates per year).
Who this book is for and what you should get out of it:
You are about to get an open source project unstuck.
Maybe a bunch of work is piling up in the repository and users are getting worried, waiting for a release. Maybe developers have gotten bogged down, trying to finish a big rewrite while maintaining the stable release. Maybe the project's suffering for lack of infrastructure — testing, money, an institutional home.
You noticed the problem. So that means it's up to you to fix it. Or you're getting paid to fix it, even though you didn't start this thing.
A while ago I blurted out the phrase "dammit-driven leadership." Because sometimes you look around, and you realize something needs doing, and you're the only one who really gets why, so you say, "Dammit, okay, I'll do it, then."
After reading this book, you should be prepared to:
- Assess a legacy project to decide whether you should get involved.
- Settle into a legacy project and become a competent and credible contributor.
- Take charge of a legacy project on a project, people, and financial level.
- Execute transformative change in a legacy project.
- Make a legacy project more sustainable, and pass leadership on to someone else.
This sampler is a free 38-page ebook (PDF, ePub, and MOBI available) that includes:
- Introduction (including my controversial? "Basic assumptions about open source and the tech industries")
- Conducting a SWOT analysis (assessing a project's strengths, weaknesses, opportunities, and threats, with example analysis of the pip project)
- How to start thinking about budgets and money (including two exercises)
- Teaching and including unskilled volunteers (with twelve specific tactics)
- An outline of the full forthcoming book
Thanks to Julia Rios for paid services editing and producing this book, including the cover! Julia is a Hugo Award-winning editor as well as a writer, narrator, and podcaster, and is available for freelance work!
A special note for my blog readers: I'm keenly interested in your feedback once you read the sampler. Have you solved any of these problems in a different way? Would a different structure, for each chapter or for the book, help you better? Did any of my examples or phrasings particularly ring true? Are there things I've written that you have found useful and that you hope I will incorporate into this book? Email me with "Unstuck" in the subject line.
Next: In 2021 I'm looking forward to finishing this book and either self-publishing or working with a publisher. And I will likely bring this sampler from behind the subscribewall once I produce a new edition of it that can have a "the full book is coming on [date] from [publisher]!" line. In order to do that, I need to finish the book proposal, submit it to publishers, and get cracking on the rest of the book.
Get the sampler for free when you subscribe to Changeset's email newsletter (1-10 updates per year).
# 11 Dec 2020, 05:50PM: Two Upcoming Sumana-Talks-At-You Events:
Most urgently: You have just over 24 hours to back the Mermaids Monthly project on Kickstarter, supporting a fun, independent speculative fiction magazine for 2021. If you back at the $100 “Subscription, Pin, and Poetry” pledge level, you'll get invited to a special Zoom party where I'll perform stand-up comedy.
And: in late January, I'll speak for the first time at Linux.Conf.Au, on "How To Get A Project Unstuck -- And Fixing The Skill Gaps That Got Us Here". You'll come away from this talk with steps you can take, in the short term and in the long run, to address this for projects you care about. Ticket sales are now open for LCA (which will of course be a virtual convention). Buy a ticket if you'd like to see my talk live and participate in questions-and-answers!
This talk will draw from the same material as the book I'm writing on getting open source projects unstuck. I aim to teach the skills open source software maintainers need, aimed at working scientists and other contributors who have never managed public-facing projects before. And I hope to have more news about that project soon!
# 07 Dec 2020, 08:55AM: Reflecting on Alexandria Ocasio-Cortez:
The other night I watched two films in a row: Knock Down The House, the documentary about four progressive candidates running to unseat Democratic incumbents in the 2018 US election, and Douglas, Hannah Gadsby's comedy special.
They're both very interesting, and afterwards I read and thought a bunch in particular about what's striking about Alexandria Ocasio-Cortez's political career.*
Making expectations explicit
In Douglas, Gadsby starts the show with a lengthy table of contents, telling you what she is going to do, saying that she would like for everyone to have their expectations properly set. She calls her shot.
In Knock Down the House I noticed a related thing that Alexandria Ocasio-Cortez did -- talking explicitly about expectations. When Crowley tried to tie her to scandalous local politician Hiram Monserrate, her retort included an explicit refutation of the de facto way that "women tend to be made responsible for the actions of every man in the room". She brings to light an implicit expectation that underlies the smear, which makes it possible for her to explicitly refuse to meet it.
In this exchange Ocasio-Cortez demonstrates one of the skills that makes her an aspirational figure, a role model for so many marginalized people: live and in the moment, she can notice an unfair or misleading criticism coming her way, refute the specific criticism, and then name and categorize what's illegitimate about the criticism so as to defuse it and get the upper hand (and point out the problem to all watching).
This is such a powerful skill. I see it in Ocasio-Cortez, in Sarah Taber, in Rep. Katie Porter, in Alexandra Erin, in Tressie McMillan Cottom, in siderea, and in some other public intellectuals and activists and politicians (often women) who are unapologetic and sharp in their fast-paced analysis of illegitimate criticism. It's like they don't just deflect the object coming their way, but they also X-ray it and show everyone the schematics so we can build our own shields too.
I don't think I have this skill. I think it really helps to have gone through the school of hard knocks, which they have way more than I have. And it helps to have a ton of practice in fast-paced live oral argument, which I've probably atrophied in recent years since so much of my work is in written conversation.
But, in organic conversation, when conflicts crop up, I think I do a tolerable job of stepping back and asking (to myself or out loud): what mismatch of expectations brought us here? Which is definitely useful.
Analytical and organizing skill
You can watch the part of Knock Down the House where Ocasio-Cortez analyzes the difference between two campaign mailers and predicts their effectiveness. This is an example of the level of skill in analysis and organizing that Ocasio-Cortez brings to her job. Which is less surprising when you remember not only that she was a promising researcher as early as high school, and that she worked as an organizer for the Sanders campaign in 2016 and got a bunch of experience in on-the-ground political work.*** The skill she demonstrates in articulating progressive arguments in compelling ways is not just a general gift of gab; it comes hand-in-hand with wonky behind-the-scenes research and thinking that brought her to those positions, and deep and specific expertise in what disengaged voters need to hear to get them to turn out at the polls.
Ocasio-Cortez's college peers remember her as brilliant and driven, often calling her "the smartest person I know" -- which reminds me of similar phrases frequently popping up in people's recollections of Hillary Rodham. The first time Elizabeth Warren met Hillary Clinton (in May 1998) she had a similar experience.
Back in October 2008 I wrote about Obama's success and noted: "people used to think the Clinton machine was the best there was. But with the right tools, investment in time, and leadership, a networked/egalitarian group will beat a linear, top-down group." Hillary Rodham went to law school instead of taking a job with Saul Alinsky's new training institute. What if she'd leaned harder into the organizing model? I think with Ocasio-Cortez you get a glimpse of what kind of independent political force she might have been.
Alexandria Ocasio-Cortez is conventionally beautiful. She is not only pretty, she frequently deconstructs beauty standards, and she has choice words for haters who think she is only pretty, but, as Tressie McMillan Cottom writes, you need to acknowledge her beauty to understand some of the dynamics around her place in politics:
I believe the right’s attacks on AOC (and a few of the left’s to be honest) are a visceral reaction to their inability to control what they see is her only legitimate source of power.....
We also feel icky about pointing out that someone is attractive and that is a certain kind of power because powerful women make us squeamish. And beauty as power makes us deeply afraid for our own self-worth.
Gadsby would probably agree with something Ocasio-Cortez says in the Vogue video (hat tip to kristi for highlighting it):
Our culture is so predicated on diminishing women and preying on our self-esteem, and so it's quite a radical act - and it's almost like a mini protest - to love yourself in a society that's always telling you you're not the right weight, you're not the right color, you're not the right, you know, whatever it is ... When you stand up and say, 'You know what? You don't make that decision. I make that decision,' it's very powerful. But that doesn’t mean we can't have fun.
Trusting one's own judgment
And, to reinforce that point about figuring out what expectations of you are legitimate, and tying that to authenticity, the Vogue article continues:
Just over two years ago, after defeating a 20-year incumbent and winning what was seen as the biggest upset of the 2018 midterm election primaries, Ocasio-Cortez was thrust into the spotlight at just 28 years old. "I went from working in a restaurant to being on cable news all the time," she recalls. "I initially really struggled with that. At a certain point, I just learned that you cannot get your feelings of beauty and confidence from anyone but yourself ... If I'm going to spend an hour in the morning doing my glam, it's not going to be because I'm afraid of what some Republican photo is going to look like ... It's because I feel like it," she says with a smile. Here, she picks up Fenty Beauty's Contour Stick, which she glides lightly down her cheekbones, over her forehead, and around her jawline. "I'm not trying to change my features or shape-shift -- I'm just trying to accentuate my existing features," she says as she adds a touch of the cream-to-powder pigment to her nose. "I'm not trying to make it look bigger. I'm not trying to make it look smaller ... I'm just trying to show people what I got."
When I get past reticence to advertise my company's services, to realistically say "I am one of the world's experts on [thing]," I too am just trying to show people what I've got. I remember N.K. Jemisin's articulation, for fiction writers:
...care better. I think the shift from extrinsic to intrinsic valuation .... is a fundamental part of the transition from amateur to professional, perhaps even more than pay rates and book deals and awards and such. .... How do you know your judgment of yourself is sound? .... But for pro writers -- and I include aspiring pros along with established ones in this designation -- it's an absolutely necessary transition. Otherwise you spend all your time caring about the wrong things.
The incentives you can see, the appealing and obvious ones, will often try to make you care about the wrong things. This means that integrity comes with inherent discomfort -- but by demonstrating integrity in public you can reduce the difficulty others run into when following your path. We've only gotten to see Ocasio-Cortez's integrity in action for a few years of public service so far. I look forward to seeing who follows her path.
* I have a caveat for Knock Down The House; it seems like the filmmakers made some misleading choices in the sequence of scenes in the NY-14 primary race.
In particular: The film makes it seem like Crowley fails to show up for a candidate forum in the Bronx (instead sending Councilwoman Palma as a surrogate), and then, maybe weeks later, he calls the Ocasio-Cortez campaign and agrees to appear on a TV debate with her. The implication is that her growing popularity, and news attention to his surrogate gaffe, have possibly shamed or scared him into agreeing to a fresh debate.
But in actual fact, the TV debate was on June 15th, and the in-person debate that Crowley skipped was a few days later, on June 18th. Here's the order things happened in, as far as I can reconstruct**:
- [not sure when]: Crowley does not attend a debate; this is not shown or mentioned in the film, but here's a tweet about it
- May 17th: AOC shows up at a Crowley office to request a debate
- May 24th: agreement to a debate on NY1
- June 15th: NY1 televised debate
- June 18th: Crowley sends a surrogate to an in-person debate in the Bronx; we see this at some length in the film
- June 21st: a somewhat quickly organized additional in-person debate (which we see briefly in the film) at the Jackson Heights Jewish Community Center (since Crowley was the chair of Queens's Democratic organization, Ocasio-Cortez wrote: "Not a single local Dem club would host a primary debate (my opponent is their Chairman). These organizers took it upon themselves to host their own."
- June 26th: Election Day
This is particularly difficult to reconcile with a bit of audio the filmmaker uses, where Ocasio-Cortez wryly says (just after we are shown footage of a Pride event from June 17th) that Crowley didn't show up to a 100-person event, but now wants to debate her on NY1.
The way I can sort of square the circle is if the filmmakers are using audio recorded before June 15th, and the skipped debate Ocasio-Cortez is referring to is the first debate that Crowley skipped (and which the filmmakers have no footage of).
In any case, the filmmakers are compressing and reordering stuff to strongly imply a particular narrative that is not congruent with the chronological record, and once I come across a discrepancy like this I gotta wonder what else in the film I should question.
** Twitter's advanced search options are helpful here, especially daterange search. Here's a search to get all of Ocasio-Cortez's tweets between May 1st and May 31st of 2018.
As long as I'm talking about the research I ended up doing for this post: Reddit user lpetrich seems to be a solid contributor to the world of AOC fandom. Thank you for your posts, lpetrich!
*** When and how did she choose to run? There's a little confusion on this point. In college she took an interest in politics as an intern for Senator Kennedy but then, as she put it, switched to more work that would have a more direct impact. She never thought she would get back into politics or policy again. So, what's the sequence of her brother nominating her to Brand New Congress, BNC's six-month vetting process, and her deciding to take that nomination? Did she hear from BNC before her road trip, or after?
# 08 Sep 2020, 10:13PM: Breaking Release Bottlenecks -- What Changeset Can Do:
I did some volunteer work earlier this year, helping rejuvenate pipenv (a command-line tool that some people use to help handle Python packages they make and use). Here's what I did, how long it took, and how you can do the same.
Pipenv's maintainers had not released a new version since November 2018, and users were concerned (in many cases switching to competitors). In early March of this year, someone suggested that perhaps the official Python Packaging User Guide should stop recommending it. I saw that suggestion and went into the relevant Internet Relay Chat (IRC) channel to nudge one of pipenv's maintainers and to ask: what do you need? What's blocking you?
Dan Ryan ("techalchemy") knew what was blocking him:
techalchemy: if you're purely evaluating 'how do we release the code', yeah I might just be the main roadblock?
techalchemy: someone to yell at me to stop doing things that are not related to the goal?
sumanah: let us assume that a successful release -- even as a pre-alpha -- is something that does not instantly break every user's life
techalchemy: yeah longer term planning though would require tech writing for sure and onboarding help, god do I struggle with that
techalchemy: have you heard me explain something...
sumanah: if you JUST want someone to yell at you to stop doing those unrelated things, just for about a month, then that can be cheaper .... would you actually _listen_ to that person?
techalchemy: historically speaking, I'd insist I was doing something important briefly but probably reassess, I do know what needs to happen
sumanah: :-) ok. So, how frequently do you need those checkins? like, 4 times a day, 5 days a week?
techalchemy: hopefully not that much, but I could see a few checkins being helpful especially if we were also onboarding some new people
sumanah: techalchemy: ~10 minutes of conversation, via IRC, 4 times a day, 5 days a week, for 3 weeks....
That would have worked out to about ten hours. We underestimated how long it would take Dan to address some nasty continuous integration bugs, so instead of three weeks it took three months. Over those months, I donated about 15 hours of my time, helping him release two betas, then a stable version in May. Given my current hourly rates, this constitutes a donation worth a few thousand dollars, which is infinitesimal compared to the value unlocked by expediting a pipenv release.
Dan needed someone to help him with prioritization, release management, and communications. So I:
Phil Gyford noticed that initial IRC conversation and said:
It's kind of fascinating as an example of bottlenecks in open source development and the importance of project managers.
And Yoz Grahame replied:
I regularly have conversations like this, and it's a toss-up as to which of the two roles I play.
Yeah. An external perspective can help a lot. And, ideally, a project manager is a supportive accountability partner who helps with the bits you're not great at.
If you/your company depends on an open source project and you're getting annoyed or worried because the release cadence has slowed to a standstill, there's a strong chance you can turn that around. If someone on your team can spend a few hours complementing the existing maintainers and helping unblock them, that could save you a bundle compared to forking or switching dependencies. Try talking with the maintainers about what they need. And I do mean talking, as in, synchronous conversation via voice or chat, so you can build some trust and get the kind of conversation you see in the IRC log above.
Or: contact Changeset Consulting for a free initial 30-minute chat. Maybe it'll only cost you a few thousand dollars to get that bottleneck unblocked. Let's find out!
# 03 Sep 2020, 11:48AM: Making Groups, Leading Them, Treating Others Well:
Some writing I've appreciated in the past year, on leadership, and on understanding others and treating them well:
synecdochic's "dreamwidth as vindication of a few cherished theories":
His decision to take energy away from his marathon coding sessions and put it into creating a positive and collaborative environment is a major reason why DW development is what it is today, and it was more than worth the extra few weeks' delay in going from closed beta to open beta.
"The Spy Who Came Home: Why an expert in counterterrorism became a beat cop" by Ben Taub:
Espionage hinges on human relationships. "The best assets I ever ran weren't in it for money," Skinner said. "They had this urge to be part of something bigger. It wasn't patriotism -- they just wanted to be part of a high-functioning team.”
Mary Anne Mohanraj's acceptance speech for her Locus Special Award for Community Outreach & Development:
So we saw a need, we came together with a group of friends and like-minded folks we gathered on the internet, and we made a thing to fix it. One of the best aspects of our genre is that it is full of such people and the organizations they’ve built.
Ada Palmer's "A Better Way of Understanding the Debate Over Free Speech on Campus":
In the nationwide debate over campus free speech, a lot of apparent disagreement derives from failing to separate the objects of study, and the habitat where study takes place.....the conditions needed to cultivate hard thought and judgment are not the same for all students...
"Doing ethical research with vulnerable users" by Bernard Tyers shares moving stories of talking with compulsive gamblers (some of whom did not know they were compulsive gamblers at the start of their conversations).
Fred Clark, Slacktivist, writes about how to deal with the dishonest weights of post-transaction surveys in "All fives (ready or not, here I come)". "You are asked questions in a language of lies and are thus forced to respond in kind."
And I deeply appreciated this essay on categories, pain, and an approach to getting better at treating others well. (This is a religious sermon that focuses on humility/love/empathy; feel free to skip, of course.) "'You're not a thing at all,' or 'The political implications of Dunbar's Number.'" is a sermon that Doug Muder (the Weekly Sift guy) presented on May 12, 2019. It's about cooperation, stories, parts we play and expect, Tolstoy, Disney, gender, inadequate and obsolete scripts, and the ideal of the perfect rulebook. Also discussed on MetaFilter.
"We want to belong, but we also want to be individuals .... I think we need to recognize that no matter how necessary it might be to simplify our experience somehow, there's always going to be an injustice in putting people into categories and dealing with them through roles and scripts. That's an injustice that we both suffer and inflict on others."
I also liked the phrase "to come into right relationship with our own pain".
# 01 Sep 2020, 01:45PM: Remedial Skills In Open-To-The-Public Working Groups:
I'm talking in this post about wikis, political clubs, open source projects, fanvidding exchanges -- any groups where people try to work together and are open to the public.
"No, what's that?"
Some people joining your groups don't know things you take for granted.
Years ago, while helping new applicants to Google Summer of Code get into working on (I think) MediaWiki or Zulip, I was talking with a person who was (at that time) a student in an Indian engineering college. He had run into trouble and was trying to debug a setup issue. He seemed to be asking for help but not systematically investigating what the problem might be.
So I said, let me give you some tips on troubleshooting. You've heard of the scientific method?
He said: no, what's that?
I gave him a link to the Simple English Wikipedia article on it -- and to the They Might Be Giants video for their song "Put It To The Test", on forming falsifiable hypotheses and testing them. I asked him to watch and read them and then tell me when he had done so. He did.
They Might Be Giants - Put It to the Test from They Might Be Giants on Vimeo.
I then said: so, you do that. You come up with a hypothesis for what might be the problem, and figure out how you would check to see if that is the case. You run the experiment, and you use the resulting data to refine your hypothesis -- if you're wrong, you try to come up with a new hypothesis. And then you either find and fix the problem, or if you get stuck, you at least have a bunch of data to give someone so they can help you better.
He said: THIS IS AMAZING! I'M GONNA USE THIS ALL THE TIME! And I was like IT IS! And then in a separate private conversation with colleagues, I was privately very angry with the educational system that had let him get that far without teaching him this!
[This is one of the experiences that led to me writing a fairly well-regarded blog post for new open source software contributors, on the scientific method, learning from and contributing to shared notes and logs, and self-reliance and interdependence.]
Some lessons here for you:
- Don't act surprised when people say they don't know something. Because (as I said a few years back) that’s just a dominance display. That's grandstanding. That makes the other person feel a little bit bad and makes them less likely to show you vulnerability in the future. It makes them more likely to go off and surround themselves in a protective shell of seeming knowledge before ever contacting you again.
- Some gaps you can remediate. Sometimes it's as quick as the explanation and links I used above. Sometimes it's more involved, as with providing free English tutoring to your internship applicants. Sometimes remediation takes a lot more work, and you may not have time to provide it; see my suggestions in "How to Teach And Include Volunteers who Write Poor Patches" which include some lower-effort options, like the section "Using their knowledge and curiosity to improve the project in other ways."
In open source projects, I think it's also okay to exclude unskilled people from a project based on "we do not have time to help them learn remedial skills, and this is not a suitable project for novices." If you are going to do this, explicit is better than implicit. You should try to forewarn contributors with explicit "not good for beginners/prerequisite skills are [list]" language in your README and CONTRIBUTORS files. And when you need to tell contributors that they aren't ready to participate in your group yet, you should offer them a redirect to a project more suitable to their skill level, you should take care not to insult them while redirecting, and you should tell them they'll be welcome back in the future after learning more of the prerequisites.
- The scientific method is still as kickass a cognitive tool as it has ever been. It's amazing and empowering!
Thanks to Dr Linda McIver for the conversation that spurred this post.
# 04 May 2020, 12:01PM: "Yes, Minister", Chesterton's Fence, And Wasteful Caution:
Just now I was in a pretty grumpy mood and it threatened to spiral further. I decided to give myself a break, got a snack and the rest of my morning tea, set a timer, hit Play on the BBC Introducing Mixtape podcast, sat facing the window and away from my laptop, and picked up The Complete Yes Minister by Jonathan Lynn and Antony Jay. And within probably ten minutes I was grinning with joy.
Jim Hacker: Humphrey, do you think it is a good idea to issue a statement?
Humphrey Appleby: Well, Minister, in practical terms we have the usual six options. One: do nothing. Two: issue a statement deploring the speech. Three: lodge an official protest. Four: cut off aid. Five: break off diplomatic relations. And six: declare war.
Hacker: Which should be it?
Appleby: Well, if we do nothing, that means we implicitly agree with the speech. If we issue a statement, we'll just look foolish. If we lodge a protest, it'll be ignored. We can't cut off aid, because we don't give them any. If we break off diplomatic relations, then we can't negotiate the oil rig contracts. And if we declare war, it might just look as though we were over-reacting.
When I was a child I saw Yes, Minister and Yes, Prime Minister on public television. What a joy. And what a clinic in getting involved with complicated systems, full of moving parts and others' motivations.
I was thinking just now about how the viewer's allegiance is caught; Jim Hacker has some good instincts about fighting for the people, but he's not as clever as he thinks he is, and he's vain and a bit lazy. And Humphrey Appleby knows how to prevent some kinds of disasters, but cannot conceive of fundamental change or the need for it. Over and over in my life in software engineering, or watching politics, or working with any collaborative group, I've seen this dynamic, though it plays out in different ways. I'm glad I got both perspectives early on, Hacker and Appleby both, to inoculate me against being purely either. I hope.
A while back I went and read about Enoch Powell, because it's always enriching to understand the previous generation's version of today's arguments and standard-bearers, even if they're horrifying. He articulated something about the same tension you find in Yes, Minister: "The right finds it easy to explain what is and to justify what is, but not to account for change. The left finds it easy to justify change, but not to account for what is, and what is accepted."
As Fred Clark says, though, in criticizing the adage of Chesterton's Fence ("If you don't see the use of it, I certainly won't let you clear it away...when you can come back and tell me that you do see the use of it, I may allow you to destroy it"), what Powell describes as "what is, and what is accepted" can be a bit of a mirage. Nearly no shared piece of infrastructure simply sits in stasis, requiring no upkeep:
Fences have to be maintained, mended, and constantly rebuilt. Fences just don't work as a metaphor for traditions, laws, and institutions handed down immutable, inviolate, and inviolable from ancient times. There's no such thing as a multi-generational fence. You don't build a fence so much as you adopt a perpetual budget for perpetual fence-building. Would-be "reformers" don't need to propose "destroying" an existing fence, they only ever need to propose that the fence-builders stop rebuilding it.
And, in practice, as Clark notes,
no matter how thoroughly we are able to come back and tell our conservative friends that we do fully understand and appreciate the original reasons for the construction of the fence, they remain unwilling to "allow" us to remove it. (The word "allow" there is worth pondering. The presumption there about who is, by definition, always a supplicant, and who holds the authority to permit or to prohibit is telling. "Allow" is, in this instance, very much a fence-builder's word.)
I also recommend Clark's followup which includes such great articulations as "fear is not the same as taking care".
Amandine Lee, discussing failure scenario generation, safety, and verification, notes:
we often push to a small percentage of real traffic, do bug-bashes and conduct pre-mortems where we imagine different types of failures and what would have caused them. We're trying to smoke out the unknown unknowns that cause issues. It's a type of thinking I am actively learning how to lean into. As an optimist, someone who tends to seek out nuance, and a person who has a strong bias towards action, I tend to chafe against risk-aversion without a clear threat model. The term "Cover Your Ass" gets thrown around to describe extreme end of this - wasteful carefulness.
...People's intuitions and risk-friendliness also vary based on personality, and how they’ve seen things fail in the past. A lot of growing as an engineer is fine-tuning that initial response to design decisions.
Sometimes have that knee-jerk caution -- I feel a reflex that leads to, as Lee calls it, "wasteful carefulness". And sometimes I am the less patient person on my team, asking others why we can't try out the idea at least in some limited way.
And now I am thinking about the symbiosis of Jim Hacker and Humphrey Appleby, how they need each other, anchor and sail. And I'm less grumpy, which was the point of the exercise anyway.
# 27 Apr 2020, 06:00PM: Remote Sprint Tips:
Every year, many developers of Python (the language itself, not just stuff written in Python) get together for a sprint. This year it will probably be virtual. How should that work? I offered to share my experiences and tips, the folks in the core development group asked me to do so, and I listed some tips. My approach is less "top-down schedule" and more "here's how to adapt to and support the emergent ways people will act".
# (1) 29 Jan 2020, 12:12PM: MOSS Video, BSSw Honorable Mention, and The Maintainership Book I Am Writing:
Mozilla interviewed me about the Python Package Index (PyPI), a USD$170,000 Mozilla Open Source Support award I helped the Python Software Foundation get in 2017, and how we used that money to revamp PyPI and drive it forward in 2017 and 2018.
From that interview, they condensed a video (2 minutes, 14 seconds) featuring, for instance, slo-mo footage of me making air quotes. Their tweet calls me "a driving force behind" PyPI, and given how many people were working on it way before I was, that's quite a compliment!
I will put a transcript in the comments of this blog post.
(Please note that they massively condensed this video from 30+ minutes of interview. In the video, I say, "the site got popular before the code got good". In the interview, I did not just say that without acknowledging the tremendous effort of past volunteers who worked on the previous iteration of PyPI and kept the site going through massive infrastructure challenges, but that's been edited (for brevity, I assume).)
This video is the first in a series meant to encourage people to apply for MOSS funding. I mentioned MOSS in my grants roundup last month. If you want to figure out whether to apply for MOSS funding for your open source software project, and you need help, ping me for a free 20-minute chat or phone call and I can give you some quick advice. (Offer limited in case literally a hundred people contact me, which is unlikely.)
The Better Scientific Software (BSSw) Fellowship Program "gives recognition and funding to leaders and advocates of high-quality scientific software." I'm one of three Honorable Mentions for 2020.
The main goal of the BSSw Fellowship program is to foster and promote practices, processes, and tools to improve developer productivity and software sustainability of scientific code. We also anticipate accumulating a growing community of BSSw Fellowship alums who can serve as leaders, mentors, and consultants to increase the visibility of those involved in scientific software production and sustainability in the pursuit of scientific discovery.
That's why I'll be at
the Exascale Computing Project Annual Meeting next week in Houston, so if you're there, I hope to meet you. In particular I'd like to meet the leaders of open source projects who want help streamlining contribution processes, growing more maintainers, managing communications with stakeholders, participating in internship projects like Google Summer of Code and Outreachy, expediting releases, and getting more out of hackathons. My consulting firm provides these services, and at ECPAM I can give you some free advice.
And here's the project I'm working on -- why I received this honor.
In 2020, I am writing the first draft of a book teaching the skills open source software maintainers need, aimed at those working scientists and other contributors who have never managed public-facing projects before.
More than developer time, maintainership -- coordination, leadership, and management -- is a bottleneck in software sustainability. The lack of skilled managers is a huge blocker to the sustainability of Free/Libre Open Source Software (FLOSS) infrastructure.
Many FLOSS project maintainers lack management experience and skill. This textbook/self-help guide for new and current maintainers of existing projects ("brownfield projects") will focus on teaching specific project management skills in the context of FLOSS. This will provide scalable guidance, enabling existing FLOSS contributors to become more effective maintainers.
Existing "how to run a FLOSS project" documentation (such as Karl Fogel's Producing Open Source Software) addresses fresh-start "greenfield" projects rather than more common "brownfield", and doesn't teach specific project management skills (e.g., getting to know a team, creating roadmaps, running asynchronous meetings, managing budgets, and writing email memos). Existing educational pathways for scientists and developers (The Carpentries, internships and code schools) don't cover FLOSS-specific management skills.
So I'm writing a sequel to Karl's book -- with his blessing -- and I'm excited to see how I can more scalably share the lessons I've learned in more than a decade of leading open source projects.
I don't yet have a full outline, a publisher, or a length in mind. I'll be posting more here as I grow my plans. Thanks to BSSw and all my colleagues and friends who have encouraged me.
# 30 Jul 2019, 01:18PM: Comparing Y2K and Climate Change:
When you know there's a big upcoming threat, how do you get big institutions to commit and follow through? And in particular, how useful is it to frighten whole populaces?
I looked into a specific claim on this topic today because a MetaFilter member compared climate change to the Y2K bug, and said,
from my POV as a computer geek who saw what it took to get the... very fine people... in management moving was panic and doom saying....
...those calm and measured meetings only took place because of the general panic. If they were going to have calm rational meetings without the outside pressure of people convinced their toasters would explode (or whatever) they'd have done it earlier.
From my POV panicking the masses, while not good, was literally the only reason the billionaires paid the slightest attention to the problem. The billionaires and the rest of the management types didn't panic, or not much anyway, but their non-panic reaction was produced entirely by the panic.
So I wanted to double-check whether that is in fact the dynamic that actually happened back in the 1980s and 1990s. Was the causality fairly simple, or was the course of events was shaped by lots of conversations among regulators, shareholders, customers, boards of directors, etc. that weren't as visible to a working engineer's point of view?
So I started looking for a little more research and data about Y2K mitigation/prevention decisionmaking especially on the institutional level, beyond the US Senate special committee report. This question -- what caused institutions to take Y2K seriously? -- seemed like the kind of thing historians of technology and organizational sociologists and political scientists must have studied. I did some digging and here are some things I think are useful to consider:
- Y2K was a technology problem at heart, and so IT investment, where IT sat in an organization, senior leaders' attitudes towards IT, etc. were factors that slowed down planning & compliance.
- Banks, for instance, found it hard to get their customers/users to understand the importance of Y2K compliance, because it was an abstruse technological issue.
- Getting companies to actually act involved some amount of influence/pressure from the outside, especially from the mass media and from regulators, state and federal agencies, and industry-wide consortia and working groups (including credible experts talking about the risk of legal liability), but also people inside companies needed to believe that the threat was not being overstated by doomsayers or IT departments seeking more turf.  
- Auditors at private companies -- whose work was often required by insurers -- did lots of disclosure, separately from anything customers or the public at large demanded via grassroots action.
- Y2K was a software problem, and so countries that made a lot of stuff but made and used way less software didn't need to do nearly as much to address it. I see a bunch of stuff in the Y2K prep literature about the US and the UK, and way less about, for instance, China.
- Companies in countries with stronger political rights and civil liberties disclosed more about their Y2K preparedness. I'd assume that disclosure made market pressure more possible (from investors and customers) but I haven't researched it.
Apologies for how much of that research is behind paywalls.
I only looked at this for a few hours but (a) I think there are a lot of important differences between the structure of the Y2K problem (and its mitigations) and climate change, and (b) I believe the story's a lot more complicated than "mass panic -> billionaires finally paid up". I think widescale media attention to the concern played a big part in directly motivating regulators and institutional decisionmakers, and grassroots concern in the general public (as citizenry and as customer base) played a part in that, but it looks like insurers and auditors and industry groups were also really crucial. To sum up, yeah, we have lessons to learn from Y2K -- I'm drawn to Bob Bennett's phrasing, that we must be Paul Revere but not Chicken Little -- but I'm very hesitant about drawing the conclusion that literally panicking the world's populaces is the only way to drive climate change mitigation.
 Ho, A. T.-K., & Smith, J. F. (2001). Information Technology Planning and the Y2K Problem in Local Governments. The American Review of Public Administration, 31(2), 158–180. https://doi.org/10.1177/02750740122064901
 Huang, J. C., Newell, S., & S-L, P. (2001). The process of global knowledge integration: A case study of a multinational investment bank's Y2K program. European Journal of Information Systems, 10(3), 161-174. doi:http://dx.doi.org/10.1057/palgrave.ejis.3000402
Backus, George, et al. "Comparing Expectations to Actual Events: The Post Mortem of a Y2K Analysis." System Dynamics Review, vol. 17, no. 3, 2001, pp. 217. doi:http://dx.doi.org/10.1002/sdr.217.
 Chang, Hsiu-Hua, Chun-Po Yin, and Huey-Wen Chou. "Diffusion of Enterprise Resource Planning Systems in Taiwan: Influence Sources and the Y2K Effect." International Journal of Enterprise Information Systems, vol. 4, no. 1, 2008, pp. 34-47. doi:http://dx.doi.org/10.4018/jeis.2008010103.
 Solomon, H. (2005, Sep 23). Y2K: The disaster that wasn't. Computing Canada, 31, 46-48.
 Clarkson, Peter M., Colin Ferguson, and Jason Hall. "Auditor Conservatism and Voluntary Disclosure: Evidence from the Year 2000 Systems Issue." Accounting and Finance, vol. 43, no. 1, 2003, pp. 21.
 S, M. W. (2004). An international investigation of associations between societal variables and the amount of disclosure on information technology and communications problems: The case of Y2K. The International Journal of Accounting, 39(1), 71-92.
# 17 Apr 2019, 09:13AM: Recurse Center, What Really Works And How We Know:
I participated in Recurse Center (formerly Hacker School) in 2013 and in 2014, and emerged a better programmer, a calmer and kinder person, and a more confident learner. Gender diversity was part of the quality of that experience:
When part of the joy of a place is that gender doesn't matter, it's hard to write about that joy, because calling attention to gender is the opposite of that....
But, as Nick Bergson-Shilcock says in "What we've learned from seven years of working to make RC 50% women, trans, and non-binary", "We focus on diversity so Recursers can focus on programming.":
In April of 2012, we announced our goal to make RC 50% women. Seven years later, we are close to reaching an improved version of this goal: 48% of new Recursers in 2019 so far identify as women, trans, or non-binary. This post is a summary of what we’ve tried, learned, and accomplished over the past seven years, as well as our overall strategy and why we choose to prioritize this work.
Bergson-Shilcock's case study shares stats, what didn't work, and what they don't know yet -- the people who run RC are consistently like this, and this writeup exemplifies their judgment, integrity, and foresight. Even when I've disagreed with RC's faculty, I have always come away from the disagreement with my trust in them intact or increased. How many institutions could I describe in that way? Not many.
One last thing -- I've recently been trying to avoid saying "community" when I really mean group, set, school, industry, project, or workplace, and Bergson-Shilcock's articulation is gonna help me do that and to value substantive communities:
Having a genuine community requires that people know the other people around them, and that everyone shares some fundamental values and purpose.
# 11 Sep 2018, 08:55AM: Now Imagine Switching The Lead Actors For Those Two Shows:
I was in the midst of talking with my pal Jed about Star Trek: The Next Generation. He'd kindly checked whether I was ok hearing criticisms of this show-of-my-heart and I said dismissiveness no, criticism yes. We talked a little about Picard. I said how interesting it is that he's an introvert leader, how we don't often see that kind of person represented on TV. (And I informed him that I want him to text me immediately once he watches "Allegiance".) But he's still collaborative and listens well to his subordinates...
And Jed said: I know you've said that Picard taught you a lot about management. But what if you got into management because of watching Picard?
Me: you did not warn me you were going to be that incisive when we started this phone call.
I mean, maybe! In some ways Star Trek: The Next Generation* is to my management style as Mad About You is to my marriage style -- the formative-influence TV show that I, sometimes even consciously, modeled myself after. But maybe it goes deeper -- maybe those are also shows that made me think it would be awesome to be a leader, and to be married.
* And Mr. Rogers' Neighborhood.
# 30 Dec 2017, 06:12PM: What We Confirm:
Unlike this nominee for a US District Court judgeship, apparently, I can at least give a one-sentence definition of the Daubert standard because of the hobby I accidentally picked up this year. Which is telling enough. But that clip and its implications also poked at some old memories for me.
As a child and as an adolescent, I generally wanted to act not just well, but defensibly well. The specific scenario that I envisioned was that I would have to answer for myself someday at a confirmation hearing before the U.S. Senate (although that was not a particularly fun way to live). Flashbulbs and microphones and wood panelling superimposed themselves on my bedroom wall.
As it turns out, I will probably never actually have that particular challenge. I took the Law School Admissions Test because my family suggested I do it to keep my options open, and got a 165, which was pretty good, but decided not to go to law school unless there was a specific thing I wanted to do that would be a lot easier if I had a law degree. Instead, I worked at a bookstore for a while, and then did customer service at Salon.com for a bit. And while there I followed the news about Hurricane Katrina, and wrote:
What we are now learning about the devastation in the Gulf combines with a growing desire, borne of my working life, to become a manager, a good one.
I reflected a few years later:
I looked at Katrina and said, "For God's sake, we have to do better than that. And I could do better!" I wanted, and still want, to reduce the net amount of mismanagement in the world. We owe ourselves competence.*
By then I was on my way in this new career. And as a non-lawyer who is only ever considered poised and diplomatic by comparison with other programmers, I find it unlikely anyone will ever nominate me for the kind of high-up government gig that would require confirmation hearings.** But I know some more things now about stewardship. I feel a special disgust and horror when I see someone else abuse a power or neglect a responsibility that I share. And the more I know, the more I can do, the more awful the sinking feeling in my chest when I see someone with less capability than me given an important task.
I'm looking back at some notes from about a year ago, just after the election:
I am predicting a future where I will ask myself innumerable times "who's minding the store?!", and seek clues as to whether a particular folly is due more to the Scylla of incompetence or the Charybdis of intentional wickedness.
[Laurie] Penny wrote that the President-Elect "has really messed with my life plan. This is far and away not the worst thing he has done, but it makes it a bit more personal." Yup. Dark humor is not usually my speed but I have found myself gasp-laughing a lot in the last couple of weeks and foresee using a lot of it in my near-future stand-up comedy. Like: of all the negative feelings I have about the election, one is the simple irritation I might feel if I were waiting at a restaurant to share dinner with a friend and they texted me, 20 minutes after they were supposed to arrive, and told me they were flaking out. It is the "but we had plans" resentment.
To that I can add another petty response I've felt a lot this year -- like Hermione Granger, bitterly asking the clearly rhetorical question, did no one else do the required reading?
Ben Franklin, in his Autobiography, recounts discovering one General Loudoun's astonishing indecision. Loudoun's procrastination slows down the entire economy of the Colonies and keeps mail boats from carrying urgent information back to England. Franklin says:
On the whole I then wondered much how such a man came to be entrusted with so important a business as the conduct of a great army, but having since seen more of the great world, and its means of obtaining and motives for giving places, my wonder is diminished.
Leonard and I sometimes now use "my wonder is diminished" with each other as shorthand for this kind of disillusionment. But I suppose I retain some capacity to be shocked-but-not-surprised, and sometimes I need to spend a little time grieving before I breathe a big sigh and put my shoulder back to the wheel -- or figure out that this means I oughta switch wheels.
* A little while after that, I read John Rogers's coining? of the term "competence porn", and have since then appreciated the "Damn, Fandom Is Good At What You Do" fanwork fest especially for this Harry Potter alternate-universe fic about property law.
** If it actually ever does happen and someone dredges up this blog post during the proceedings, I hope I have the sense of humor to laugh about it.
# 11 Nov 2017, 08:14AM: Video of Our PyGotham Play:
You can now watch the 22-minute video of the play I discussed last month. "Code Review, Forwards and Back", co-written by and co-starring Jason Owen and me, directed by Jonathan Galvez.
- Kenneth Durril for running sound
- David Beazley for running lights (on a few hours' notice and with no rehearsal)
- A. Jesse Jiryu Davis for a cameo as a junior engineer, and for introducing the play
- Jonathan Galvez for directing (if you're in NYC and looking to hire a director for a thing like this, ask me for his email address)
- Michael Rehse for a ton of useful advice
- Laura Hampton for serving as a dramaturg during late rehearsals
- The PyGotham organizers for accepting the talk and advising us on logistics and tone
- Our audience, especially attendees who told us they'd liked it
We were happy to hear people say things like I'm new to the industry, and this helped me learn things to watch out for or I used to be that reviewer and I'm trying not to be anymore or My name is Randall and I never hear my name in fiction and it was nice to hear you say my name or I don't code at all but this is a marvelous management parable. Indeed, code review is just a particularly visible moment where you can see the effects of an organization's culture and processes. Too execution-focused (the right hand doesn't know what the left hand is doing)? Too alignment-focused (we're taking so much time deliberating and gaining consensus that we can't make forward progress on the mission)? Too lax, or too superficial, in enforcing rules? Our play can't dive into every scenario but it's a start. And -- the most frequent comment we got from happy attendees -- it was a change of pace (no slides!).
We're revising the play and submitting this a few other places; once it's run its course, we'll be posting the text of the script online.
# 05 Sep 2017, 03:38PM: From Conversation:
A few recent thoughts.
- The power of "instead": One of the transdisciplinary lessons from Agile is that it's harder for most people to specify "this is what I need" than to look at a suggested solution and talk through "here's why this doesn't work for me." Another way to see this: generating initial idea-seeds is a useful gift, even if we don't implement any of them, if discussing them leads to us figuring out what we really want. "Instead" is a goldmine.
- Margaret Killjoy's fiction: I was talking with friends about Margaret Killjoy's fiction the other night and realized I should gush about it someplace where more people will see.
In late 2016 and early 2017, the two books that remedied the political doom in my head were Cory Doctorow's Walkaway (you can read the accompanying novella Party Disclipine for free) and Rebecca Solnit's Hope in the Dark (I have not finished this yet but have found a lot of solace in it). Now I've found a third: Margaret Killjoy's novella The Lamb Will Slaughter the Lion. It's so perceptive "about the lure of authority" and about all the microreactions we have when we meet new acquaintances and decide how much to trust them, and thrilling (although if a bit of horror gore squicks you out, you might want to sit this one out). Like Killjoy's "Men of the Ashen Morrow" and "Everything that Isn't Winter" it's also a closely observed story about violence, loyalty, vulnerability, sacrifice, and the ways we try to influence each other when we don't have traditional capitalist/bureaucratic hierarchies to bring to bear.
In "Everything that Isn't Winter", our point-of-view character is a resident and guard of an egalitarian commune, itchy and melancholy about their own too-well-developed capacity for and comfort with violence. I found it refreshing to see the competence demonstrations, loyalty, sacrifice, tradecraft, and suspense I'd usually see in military SF deployed in a story about the defense of an egalitarian commune in the woods.
The Lamb Will Slaughter the Lion (available as an ebook for NYPL patrons to borrow via the SimplyE app for Android and iOS) particularly spoke to me in its attention to the subtleties of power and influence, especially in nonhierarchical organizations -- it brings the fantastic lens to "The Tyranny of Structurelessness". What does it feel like and what happens, within each of us and among us, when our inability to persuade others to take urgent collective action collides with the heartfelt desire to avoid dominating others?
Killjoy's fiction, like Walkaway and Party Discipline, shows us not just arguments people might say or think in the service of a freer life, but the forms those lives might take, the feelings and relationships that would emerge. Narrative gives us people to love and to imagine ourselves in community with. Recently I read lazenby's essay on the body as compared to art or love:
Art, as Ruskin wants it to be seen, is a co-equal portal of creation through which it is possible to glimpse a world that is something other than the vigorous hybrid of cleverness and sadism....
In rather the same way that art does not rely on the logic of power or the power of logic, its example allows us to see still other ways of thinking....
I attended a Regina Spektor concert a few weeks ago that felt numinous. Live music, like great narrative, is one of those magic things for me. If you have been feeling airless and sewn to the ground, I hope you find a chunk of magic somewhere that helps you.
- Wedding bells: My friends got married! Awwwww.
# (1) 07 Apr 2017, 03:36PM: 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: 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: 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 feedback-at-zulip.com, 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 chat.zulip.org, 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 chat.zulip.org. 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 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).
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:
- a disconnect among the different "places" such that the central bug tracker is a black hole and nothing gets reported back to the more accessible place or the original reporter
- a feeling of elitism where only special important people are allowed to even comment in the main bug tracker
- bottlenecks such that it seems like there's a non-bug-tracker way to report a question or suggestion but that process has creaked to a halt and is silently blocking momentum
- bottlenecks in bug triage
- brusque reaction at the stage where the bug report gets to the central bug tracker (e.g., "oh that's a duplicate; CLOSE" without explanation or thanks), which jars the user (who's expecting more explicit friendliness) and which the user perceives as hostile
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.
# (1) 04 Apr 2017, 12:37PM: How to Teach And Include Volunteers who Write Poor Patches:
You help run an open source software community, and you've successfully signalled that you're open to new contributors, including people who aren't professional software engineers. And you've already got an easy developer setup process and great test coverage so it's easy for new people to get up and running fast. Great!
Some of the volunteers who join you are less-skilled programmers, and they're submitting pull requests/patches that need a lot of review and reworking before you can merge them.
How do you improve these volunteers' work, help them do productive things for the project, and encourage and include them?
My suggestions for you fall into three categories: helping them
improve their code, dealing with the poor-quality pull requests
themselves, and redirecting their energies to improve the project in other ways.
Teaching them to improve their code
- Collect and suggest relevant learning resources, like certain talk recordings or freely available articles/exercises (e.g. The Architecture of Open Source Applications), and ask them to come back after they've watched/read/done them. Example: Zulip's collection.
- If developers have trouble writing good comments and commit messages, or diving into the codebase to find relevant files and commits, point them to my blog post "On the scientific method and usable history". It explains why it's important to do that, and gives them pointers.
- Ask more experienced contributors to pair program with them, both as leader and as follower. Here are a few tools to help.
- Run live coding exercises, over chat or video, where an experienced developer speaks aloud as she writes a bugfix, including all the little steps like searching for related commits, setting up and running tests, etc. This enables newer developers to learn a lot of tips that help them work faster and write higher-quality code. I've done this at Wikimedia with live video and we use Zulip for a live text approach (see Alicja Raszkowska's transcript and notes of one such session).
- If a big problem with their submissions is poor English writing skills, run some English tutoring sessions.
Dealing with poor patches themselves
Using their knowledge and curiosity to improve the project in other ways
This list is absolutely not the be-all and end-all for this topic; I'd like to know what approaches others use.
- Ask these developers to write "discovery reports". They're already user-testing your developer onboarding process; ask them for their experiences, so you can find and fix pain points.
- Ask them to run through some manual testing (example manual testing guide from Zulip), and to tell you how long certain kinds of tests took, so you can get bug reports and improve the docs.
- Ask them to teach about your project in their communities -- to develop learning and presentation materials and speak at meetups. You may have just found your most enthusiastic marketer.
Thanks to Noah Swartz for starting a conversation at Maintainerati that spurred me to write this post.
# 16 Mar 2017, 05:37PM: What Does An Award Do?:
I posted on MetaFilter about the new Disobedience Award that MIT Media Lab is starting (nomination deadline: May 1st). And in the comments there, I stumbled into talking about why one might found an award, and thought it was worth expanding a bit here.
I think anyone who thinks for a second about awards -- assuming the judgment is carried out in good faith -- says, well, it's to reward excellence. Yup! But what are the particular ways an award rewards excellence, and when might an award be a useful tool to wield?
Let's say you are an organization and you genuinely want to celebrate and encourage some activity or principle, because you think it's important and there's not enough of it, particularly because there are so many norms and logistical disincentives pushing to reduce it. For example, you might want to encourage altruistic resistance. Let's say your organization already has a bunch of ongoing processes, like teaching or making products or processing information, and maybe you make some changes in those processes to increase how likely it is that you're encouraging altrustic resistance, but that isn't really apparent to the world outside your doors in the near term, and the effects take a while to percolate out.
So maybe you could set up an award. An award can:
- get publicity for the idea that altruistic resistance is a thing to celebrate
- help one specific person or group who's currently practicing altruistic resistance keep going, with money and attention, and make a big difference to their stamina and effectiveness
- maybe bring attention to a list of finalists and help their work get more coverage
- ensure the award administrators (and any judging committee involved) and, to a lesser extent, the reporters covering the award, will spend time thinking about the importance of altruistic resistance
- cause a bunch of people to think "hmm, whom should I nominate?" and write a couple paragraphs about why their work is good and award-worthy (and, by causing that writing, also solidify the nominators' commitment to respecting and rewarding altruistic resistance)
- demonstrate your institutional commitment to altruistic resistance, potentially sending a hard-to-ignore message to your future self to guide future decisions
And if an award keeps going and catches on, then people start using it as a shorthand for a goal. New practitioners can dream of winning the acclamation that a Pulitzer, a Nobel, a Presidential Medal of Freedom carries. If there's an award for a particular kind of excellence, and the community keeps records of who wins that award, then in hard moments, it can be easier for a practitioner to think of that roll call of heroes and say to herself in hard moments, "keep on going". We put people on pedestals not for them, but for us, so it's easier for us to see them and model ourselves after them.
So, all awards are simplistic summative judgments, but if the problem is that we need to balance the scales a bit, maybe it'll help anyway.
Nalo Hopkinson is doing it via the Lemonade Award for kindness in the speculative fiction community. The Tiptree Award does it for the expansion & exploration of gender. Open Source Bridge does it for community-making in open source with the Open Source Citizenship Award for "someone who has put in extra effort to share knowledge and make the open source world a better place."* It's worth considering: in your community, do people lack a way to find and celebrate a particular sort of excellence? You have a lot of tools you could wield, and awards are one of them.
* I realized today that I don't think the list of past Open Source Citizenship Award recipients is in one place anywhere! Each of these people was honored with a "Truly Outstanding Open Source Citizen" medal or plaque by the Open Source Bridge conference to celebrate our engagement "in the practice of an interlocking set of rights and responsibilities."
# (1) 31 Oct 2016, 11:47AM: 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.
# 27 Oct 2016, 11:06AM: Learning Styles:
For years, while mentoring others, I've been using these engineering learning styles as a tool to help newer engineers reflect on how they learn, and to give them a sense of the possible toolbox of learning approaches, so that if they get stuck, they can recognize what approach they're using and try another one. But students don't have different learning styles, really, per science-based required reading for a Software Carpentry train-the-trainer class I'm about to attend. I need to rework my advice.
# 04 Aug 2016, 03:51PM: 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!
# 23 May 2016, 10:02AM: Two OSCON Conversations, And A Trip Report Between Them:
Conversation the last night of OSCON, reconstructed from memory:
"So, Neil Young --"
"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?"
In 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:
- Breaking the no-electronics rule of the quiet room/relaxation lounge (since I was the only one using it) to finish revising my talk and blog about good code review
- Staying with some lovely relatives in the suburbs for a few days and drinking spinach juice with them each morning (my uncle is in charge of making it, and sometimes he adds grape or orange juice, and sometimes something else, and sometimes it's just spinach. It's a surprise. "Every day's a new day," he said to me)
- Helping my high schooler cousin revise a skit, and deploying my stand-up comedy wisdom, e.g., use over-the-top worshipful admiration as a kinder substitute for straight-up mockery
- Being the only person in the pool at the Software Freedom Conservancy party (foolish choice on my part; it was pretty cold)
- Meditating on a loved one during an exercise in Cate Huston's talk on technical interviewing, and feeling the lovingkindness throughout the whole room
- Listening to an enthralling performance by rapper Sammus
- Becoming increasingly convinced that continuous integration/continuous delivery is hitting an inflection point that source control hit several years ago, i.e., soon it will be a must-have for software-making communities and not having it will be embarrassing
- Chatting with OSCON acquaintances in an Austin hotel lobby and being interrupted by a drunk white woman who called me "Mindy Lahiri" (a fictional character from The Mindy Project)
- Opting out of the millimeter-wave scanner at the Austin airport and witnessing a person wearing an EFF shirt not opt out!
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.
# 21 Mar 2016, 04:58PM: 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.
# 23 Feb 2016, 04:00PM: Leadership Crisis at the Wikimedia Foundation:
This week, the Wikimedia Foundation, the main organization supporting Wikipedia and several other free knowledge projects, is at the peak of a leadership crisis more than a year in the making. Molly White's timeline of the crisis is a useful guide to the facts, and I feel compelled to speak publicly for the first time about the problem, and share my personal perspective, with a bit of context to help non-Wikimedians understand.
I left the Wikimedia Foundation in September 2014 after four years. I mentioned the reasons then, in that post, around learning new things and working on projects with less of a public spotlight. I'm happy with my new direction, Changeset Consulting LLC, but still have so many fond memories of working with fantastic people and making a difference.
I left WMF thinking that it was fine -- in fact, that's a reason I felt okay about deciding to leave a place I cared about so much, because I thought WMF could cope without me. As I perceived it, former Executive Director (nonprofit-speak for "CEO" basically) Sue Gardner had led the organization to a stable enough place that she felt free to move on. For years, when I was at Wikimedia Foundation, our top priority was reversing the decline in the number of active Wikipedia contributors and other Wikimedia contributors; Sue Gardner articulated this priority and ensured everyone knew what we were aiming at and why. Lila Tretikov, the new executive director, was settling in and I perceived WMF to be on the right track, iteratively moving closer to reversing the editor decline, with solid management and plans in place to keep positive momentum going. I thought the conflicts and stumbles from summer 2014 were normal temporary pains, not unusually worrying.
A few months after I left, when I caught up with old Foundation colleagues, I started hearing wariness about the new high-level management (the ED and some other newer executive hires). The worries progressed into stronger and stronger concerns, getting more and more disturbing. For instance, in November 2015, a committee that disseminates Wikimedia funds to budget other Wikimedia institutions (such as chapters) wrote a scathing critique:
...the [Funds Dissemination Committee] laments that the Wikimedia Foundation's own planning process does not meet the minimum standards of transparency and planning detail that it requires of affiliates applying for its own Annual Plan Grant (APG) process....
The FDC is appalled by the closed way that the WMF has undertaken both strategic and annual planning, and the WMF's approach to budget transparency (or lack thereof).
I nearly could not believe my eyes when I saw this. For those of you who don't follow these bureaucracies, let me assure you that the FDC does not throw around words like "appalled" lightly. (Followup on the FDC recommendations.)
Early this year, it became public knowledge that the conflicts within the Foundation had led to an employee survey with a 93% response rate. The results included:
I have confidence in senior leadership at Wikimedia: 10% agree
It is a miracle if 90% of Wikimedia Foundation personnel agree on anything beyond the fact that WMF's commitment is to "a world in which every single human being can freely share in the sum of all knowledge." And to be clear, "confidence in senior leadership" here means that the employees trust that the C-level executives have the basic competence to run the organization. This isn't about agreeing or disagreeing on particular choices of method; when I was at WMF, the Executive Director and the Chief ____ Officers made decisions that some employees disagreed with, but they explained their reasoning, they encouraged feedback and responded to it (example), and we fundamentally knew they were aiming to collaborate with us in achieving the mission. It sounds like some big pieces of that trust are now missing.
1. In late December the Board of Trustees dismissed a well-liked community-elected trustee, Dr. James Heilman, for reasons that remain somewhat mysterious...
3. Revelations about newly appointed Board trustee Arnnon Geshuri's involvement in an illegal anti-poaching scheme while at Google has drawn community outcry
4. Besides failing to vet Geshuri, the WMF's increasing tilt toward the Silicon Valley and focus on (perhaps) the wrong technology projects have come into sharper relief
So, Arnnon Geshuri. You know that scandal where it came to light that big Silicon Valley tech firms were colluding to suppress wages and reduce employee mobility with illegal "no-poaching" agreements? With evidence including super damning emails? Guess who sent some of that email, perpetuating that pact? Arnnon Geshuri. The WMF Board of Trustees appointed him as one of the trustees. He's since stepped down but the incident damaged already-shaky trust between the Board and the larger Wikimedia community.
And as of last week it's clear that the situation's gotten even more dire. Fantastic colleagues are voting with their feet and leaving (and do you know how hard it is to find and hire the right people for an org this weird and this important?). People who would rather walk with rocks in their shoes than throw their coworkers under the bus are compelled to speak in public about dysfunction at the top: Ori Livneh, Anna Stillwell, and Greg Grossmeier, for instance, and Brion Vibber, who was the first employee the Foundation ever hired. Faidon Liambotis, Principal Operations Engineer at the Foundation & a longtime Debian Developer. Gayle Karen Young, former WMF Chief Talent & Culture Officer, who has a world-class ability to fuse compassion and systems-level thinking in the management of people processes, writes publicly about "dysfunction at the top" and "the enormous toll" it's taking on the staff. Erik Möller, who served on the Board of Trustees before he served as WMF second-in-command for more than seven years and then left in April 2015, a guy who has seen a thousand Wikimedia thunderstorms come and go and could probably charge for calm-as-a-service, says that "the situation is very much out of control" and "this is a crisis". This is not just the ordinary grumblings of a transparent organization. This is dire.
Executive Director Lila Tretikov said on Monday that Wikimedia has now managed to stem the editor decline. Möller replies and asks: is that so? and reviews the current stats, which do not reflect this claim.
But overall, it seems premature of speaking of "stemming the decline", unless I'm missing something (entirely possible).
There have been a thousand thunderstorms before. The Image Filter, SOPA, the transition from Toolserver to Tool Labs, Narrowing Focus, paid editing, the first VisualEditor rollout, the India Education Program, I could keep going and the point is that we Wikimedians have big ideas and big passionate arguments and we know some things about how to get through them. The movement, thank goodness, is bigger than the Foundation. The volunteers, the chapter staff, the teachers and photographers and coders and editors and everyone in the hundreds of subcommunities in our ecology have some buffers against the ripples coming out of the Foundation. There's frustration, sometimes, in how hard it can be for one subcommunity or organization to persuade or lend a hand to another, but right now it's a good thing because there is short-term resilience in that loosely federated structure.
This has been a singularly destructive time, but we still have time to keep the leadership problem from further damaging the Wikimedia movement.
As I said back in September 2014,
One of the things I admire about Wikimedia's best institutions is our willingness to reflect and reinvent when things are not working.
I don't know what the answer is.
The choice between exit and voice is conditioned on loyalty. We know that Wikimedians have been exercising the "voice" option; the Board and the ED have heard these criticisms loud and clear. And we know they've witnessed the stream of talented employees exiting, their steel-clad loyalty finally succumbing to the pressure. If unaltered, this is the kind of dynamic that leads to schisms and forks. I would hate for the movement to have to pay that kind of cost but, unless the Wikimedia Foundation Board of Trustees and Executive Director change course, I think that's a potential outcome.
# 19 Feb 2016, 06:50PM: 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.
I'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:
- We planned this thing: __________________________
- This is how we knew it wasn't working: __________________________
- There might have been some issues with our assumption that: __________________________
- If we tried it again, we might change: __________________________
Little 'f' failure framing:
- We planned this thing: __________________________
- This is how we knew it wasn't working: __________________________
- We think that this went wrong: __________________________
- 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
# 09 Aug 2015, 10:52PM: 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. (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.)
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."
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.
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.
# (1) 25 Dec 2014, 12:48AM: Good And Bad Signs For Community Change, And Some Leadership Styles:
So let's assume you want to improve a particular community, and you've already read my earlier pieces, which I am now declaring prerequisites: "Why You Have To Fix Governance To Improve Hospitality", "Hospitality, Jerks, and What I Learned", and "Learn Tech Management in 45 Minutes" (all the way through the Q&A). And let's assume that you care about the community having a good pathway to inclusion, and that the community is caring or collaborative, rather than cordial, competitive, or combative.
When I look at an open stuff community, here are some factors that
make me optimistic:
- people with social capital in the project, whom other participants respect, support my goals in private conversation
- even better: such people have reached out to me, of their own
initiative, about it
- even better than that: such people are already taking real action
- I have personal relationships with at least one influential project leader
- I am in the private spaces where project leaders talk
- either the project's still new and the norms are in flux, or there's a new initiative or subcommunity where I can influence norms or even amend the rules of the game before they jell and harden
- the founder of the project exercises charismatic/inertial authority and either does not support my goals, or is too afraid of conflict to take real action
- per Selena Deckelmann's advice, "If someone is treating you with contempt, or you are using contempt in arguments, that's a big warning sign."
- there is a private space where important conversation happens and I'm not invited
- I, or someone else who shares my goals, has been unsuccessful in
getting the community to do something small towards my goals. For instance, assuming my goal is improving gender diversity in a male-dominated workplace, I haven't been able to get them to adopt a first code of conduct, or improve a CoC to have real enforcement provisions, or participate in a women-centric job fair, or make a token effort towards diversity in guest speakers.
- not just the rules of the game, but the dominant worldview, and perhaps the major actors, haven't changed in, say, more than three years
To achieve change in this kind of situation, you have to have enough social skills to be able to make relationships, to notice whether contempt has made an appearance, to grok the subtle stuff. A systems approach (leader as engineer) will get you part of the analysis and part of the solution; you also need relatedness (leader as mother). Requisite variety. In the face of a problem, some people reflexively reach more for "make a process that scales" and some for "have a conversation with ____"; perhaps this is the defining difference between introverts and extroverts, or maybe between geeks and nongeeks, in the workplace.* We need both, of course - scale and empathy.
A huge part of my job for the last four years was struggling with the question: how do you inculcate empathy in others, at scale, remotely? How do you you balance genuine openness to new people, including people who think very differently from you, with the need for norms and governance and, at times, exclusion?
Huh, I wonder whether this is the first blog entry I've ever tagged both with "Management and Leadership" and "Religion".
# (1) 21 Dec 2014, 11:10PM: Why You Have To Fix Governance To Improve Hospitality:
Fundamentally, if you want to make a community hospitable,* you need to work not just on individual rules of conduct, but on governance. This is because
- the particular people implementing rules of conduct will use their judgment in when, whether, and how to apply those rules, and
- you may need to go a few levels up and change not just who's implementing rules, but who's allowed to make rules in the first place
Wait, how does that work?
In my Wiki Conference 2014 keynote address (available in text, audio, and video), and in my PyCon 2014 poster about Hacker School, I discuss how to make your community hospitable. In those pieces I also mention how the gatekeeping (there is an initiation/selection process) and the paid labor of community managers (the facilitators) at Hacker School help prevent or mitigate bad behavior. And, of course, the Hacker School user manual is the canonical document about what is desired and prohibited at Hacker School; "Subtle -isms at Hacker School" and "Negative comments" have more ruminations on how certain kinds of negativity create a bad learning environment.
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 but that I did not experience at Hacker School and thus that I noticed more after my sabbatical at Hacker School: 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.
You can try to make rules about how things ought to be, about what is allowed and not, but members of the incumbent/dominant group are less accustomed to monitoring their own behavior, as the Onlinesmanship wiki (for community moderators) reminds us:
Another pattern of the privileged: not keeping track of the line between acceptable and unacceptable behavior. They only know they've crossed the line when someone in authority tells them so. If this doesn't happen, their behavior stays bad or gets worse....
Do not argue about their intentions. They'll swear they meant no harm, then sulk like fury because you even suggested it. In most cases they'll be telling the truth: the possibility that they were giving offense never crossed their minds. Neither did any other scenario, because unlike real adults, they take no responsibility for getting along with others. The idea that in a cooperative work situation, getting along with one's fellow employees is part of the job, is not in their worldview.
This too is a function of privilege. They assume they won't get hit with full penalties for their first offense (or half-dozen offenses), and that other people will always take on the work of tracking their behavior, warning them when they go over the line, and explaining over and over again what they should have done and why. It's the flip side of the way people of the marked state get hit with premature negative judgements (stupid, dishonest, sneaky, hysterically oversensitive) on the basis of little or no evidence.
And, in any community, rules often get much more leniently interpreted for members of the dominant group. And this is even harder to fight against when influential people believe that no marginalization is taking place; as Abi Sutherland articulates: "The problem with being lower on an unstated social hierarchy is that marginal judgment calls will
reliably go against you. It's an excusable form of reinforcement."**
Changing individual rules isn't enough. After all, individual rules get made by particular humans, who -- here, instead of babbling about social rule system theory at you, I'll give you a sort of sidebar about three successive levels of governance, courtesy of my bachelor's degree in political science:***
- Actors: The actual set of people who run an organization or who shape agendas, on any given day, have particular ideas and policies and try to get certain things done. They implement and set and change regulations. Actors turn over pretty fast.
- For example, in its five-year history, Hacker School has had employees come and go, and new participants have become influential alumni.
- Dominant worldviews: More deeply and less ephemerally, the general worldview of the group of people who have power and influence (e.g., Democrats in the executive branch of the US government, sexists in mass media, surgeons in operating rooms, deletionists on English Wikipedia) determines what's desirable and what's possible in the long term. Churn is slower on this level.
- For example, dominant worldviews among Hacker Schoolers**** include: diversity of Hacker Schoolers, on several axes, helps everyone learn more. Hiding your work, impostor syndrome, too much task-switching, and the extrinsic motivation of job-hunting are common problems that reduce the chances of Hacker Schoolers' success. Careers in the tech industry are, on balance, desirable.
- Rules of the game: What is sacred? What is so core to our identity, our values, that breaking one of these means you're not one of us? The rules of the game (e.g., how we choose leaders, what the rulers' jurisdiction is) confer legitimacy on the whole process. Breaking these rules is heresy and amending them is very hard and controversial.***** Publicly disagreeing with the rules of the game costs lots of political capital.
- For example, the rules of the game among Hacker Schoolers, as I see them, include: the founders of Hacker School and their employees have legitimate authority over admissions, hiring, and rule enforcement. Hacker School is (moneywise) free to attend. Admission is selective. A well-designed environment that helps people do the right thing automatically is better than one-on-one persuasion, which is still better than coercion.
(Where do the four Hacker School social rules fall in this framework? I don't know. Hacker School's founders encourage an experimental spirit, and I think they would rather stay fluid than accrete more and more sacred texts. But, as more and more participants have experienced a Hacker School with the four social rules as currently constituted, I bet a ton of my peers perceive the social rules as DNA at this point, inherent and permanent. I'm not far from that myself.)
(I regret that I don't have the citation to hand, and would welcome the name of the theorists who created this model.)
So, if you want a hospitable community, it's not enough to set up a code of conduct; a CoC can't substitute for culture. Assuming you're working with a pre-existing condition, you have to assess the existing power structures and see where you have leverage, so you can articulate and advocate new worldviews, and maybe even move to amend the rules of the game.
How do you start? This post has already gotten huge, so, I'll talk about that next time.
* I assume that we can't optimize every community or activity for hospitality and learning. Every collaborative effort has to balance execution and alignment; once in a while, people who have already attained mastery of skill x just need to mind-meld to get something done. But if we want to attract, retain, and grow people, we need to always consider the pathway to inclusion. And that means, when we accept behavior or norms that make it harder for people to learn, we should know that we're doing it, and ask whether that's what we want. We should check.
**See the second half of "One Way Confidence Will Look" for more on the unwillingness to see bias.
*** I am quite grateful for my political science background -- not least because I learned that socially constructed things are real too, which many computer science-focused people in my field seem to have missed, which means they can't mod or make new social constructs as easily. Requisite variety.
**** A non-comprehensive list, of course. And I don't feel equal to the more nuanced question: what beliefs do the most influential Hacker Schoolers hold, especially on topics where their worldview is substantially different from their peers'?
***** The US has a very demanding procedure for amending the Constitution. India doesn't. The US has had 27 amendments in 227 years; India, 98 in 67 years. I don't know how to interpret that.
# 28 Nov 2014, 06:48PM GMT+5:30: Normal's Just A Setting On The Dryer:
(Title from some lost-to-the-ages sage, I think.)
I recently said to a friend that I'm pretty on-board with "Labels are for mailing things" and "Normal's just a setting on the dryer" (also said as "Normal: of or pertaining to someone named Norm"). I also shy away from calling things "real", from using the minimizing adverb "just", from saying that "everyone" does or is or doesn't or isn't something.
Today I was thinking about the assumptions that US children of immigrants make, about the fact that we know that "normal" is relative. When I'm in Mysore, it's as normal to sidestep cow poop on the road as it is to avoid clicking on phishing links in my email.
Evidence is mounting that several people consider me a role model and a leader. (And yes if you thought "that must be something Sumana is resistant to acknowledging, to herself or publicly" then you are accurate in your predictions!) So I'm mulling that. Role models demonstrate that something is possible, for, lo, here is an existence proof. And leaders get to influence perceptions of what's normal, and what's bullshit.
# 08 Oct 2014, 08:01AM: How I made a tidepool: Implementing the Friendly Space Policy for Wikimedia Foundation technical events:
Back when I worked at the Wikimedia Foundation, I used the Ada Initiative's anti-harassment policy as a template and turned it into the Friendly Space Policy covering tech events run by WMF. I offer you this case study because I think reading about the social and logistical work involved might be inspiring and edifying, and to ask you to please donate to the Ada Initiative today.
I was working for Wikimedia Foundation for ~8 months before I broached the topic of a conference anti-harassment policy with the higher-ups - my boss & my boss's boss, both of whom liked the idea and backed me 100%. (I did not actually ask HR, although in retrospect I could have.) My bosses both knew that Not So Great things happen at conferences and they saw why I wanted this. They said they'd have my back if I got any flak.
So I borrowed the Ada Initiative's policy and modified it a little for our needs, and placed my draft on a subpage of my user page on our wiki. Then I briefly announced it to the mailing list where my open source community, MediaWiki, talks. I specifically framed this as not a big deal and something that lots of conferences were doing, and said I wanted to get it in place in time for the hackathon later that month. Approximately everyone in our dev community said "sure" or "could this be even broader?" or "this is a great idea", as you can see in that thread and in the wiki page's history and the talk page.
I usually telecommuted to WMF, but I happened to be in San Francisco in preparation for the hackathon, and was able to speak to colleagues in person. My colleague Dana Isokawa pointed out that the phrasing "Anti-harassment policy" was offputting. I agreed with her that I'd prefer something more positive, and I asked some colleagues for suggestions on renaming it. My colleague Heather Walls suggested "Friendly Space Policy". In a pre-hackathon prep meeting, I mentioned the new policy and asked whether people liked the name "Friendly Space Policy," and everyone liked it.
So I made it an official Policy; I announced it to our developer community and I put it on wikimediafoundation.org.
This might have been the end of it. But a day later, I saw a question from one community member on the more general community-wide mailing list that includes other Wikimedia contributors (editors/uploaders/etc.). That person, who had seen but not commented on the discussion on the wiki or on the developers' list, wanted to slow down adoption and proposed some red tape: a requirement that this policy be passed by a resolution of the Wikimedia Foundation's Board of Trustees (so, basically, the ultimate authority on the topic).
But approximately everyone on the community-wide list also thought the policy was fine -- both volunteers and paid WMF staffers. For instance, one colleague said:
"If a policy makes good sense, we clearly need it, and feedback about the text is mostly positive, then we should adopt it. Rejecting a good idea because of process wonkery is stupid.
Sumana is not declaring that she gets to force arbitrary rules on everyone whenever she wants. She is solving a problem for us."
My boss's boss also defended the policy, as did a member of the Board of Trustees.
"Perhaps you misread the width of this policy. Staff can and generally do set policies affecting WMF-run processes and events."
I didn't even have to respond on-list since all these other guys (yes, nearly all or all guys) did my work for me.
I was so happy to receive deep and wide support, and to help strengthen the legitimacy of this particular kind of governance decision: consensus, including volunteers, led by a particular WMF staffer. And, even though I had only proposed it for a particularly limited set of events (Wikimedia-sponsored face-to-face technical events), the idea spread to other affiliated organizations (such as Wikimedia UK) and offline events (Wikimania, our flagship conference -- thank you, Sarah Stierch, for your work on that!). And the next year, a volunteer led a session at Wikimania to discuss a potential online Friendly Space Policy:
"Explore what elements are essential for you in such a policy and what we can do collectively to adopt such a policy for Wikipedia and other Wikimedia websites."
So perhaps someday, all Wikipedia editors and other Wikimedia contributors will enjoy a safer environment, online as well as offline! I feel warm and joyous that the discussion I launched had, and is having, ripple effects. I felt like I took a gamble, and I looked back to see why it worked. A few reasons:
- The Ada Initiative's template. I cannot imagine writing something that good from scratch. Having that template to customize for our needs made this gamble possible at all.
- I started the discussion in January 2012; I had joined Wikimedia Foundation (part-time) in March 2011. So I had already built up a bunch of community cred and social capital.
- In early 2012, open source citizens saw more and more reports of hostile behavior at conferences; people saw the need for a policy.
- I added "or preferred Creative Commons license" to the big list of attributes (gender, disability, etc.), which gave the document a touch of Wikimedia-specific wit right at the start of the policy.
- I balanced decisiveness and leadership with openness to others' ideas.
- Honestly, I narrowly focused the policy to an area where my opinion carried weight and I held some legitimate authority (both earned and given), phrased my announcement nonchalantly and confidently, and ran the consensus process pretty transparently. I believe it was hard to disagree without looking like a jerk. ;-)
(If you can privately talk with decisionmakers who have have top-down authority to implement a code of conduct, then you can use another unfortunate tool: point to past incidents that feel close, because they happened to your org or to ones like it.)
By implementing our Friendly Space Policy, I created what I think of as a tidepool:
"...places where certain people can sort of rest and vent and collaborate, and ask the questions they feel afraid of asking in public, so they can gain the strength and confidence to go further out, into the invite-only spaces or the very public spaces....spaces where everybody coming in agrees to follow the same rules so it's a place where you feel safer -- these are like tidepools, places where certain kinds of people and certain kinds of behavior can be nurtured and grown so that it’s ready to go out into the wider ocean."
With the help of the Ada Initiative's policy adoption resources, you can make a place like that too -- and if you feel that you don't have top-down authority, perhaps that no one in your community does, then take heart from my story. If you have a few allies, you don't have to change the ocean. You can make a tidepool, and that's a start.
# (1) 13 Aug 2014, 03:48PM: 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.
- A team of mentors. I gathered a co-mentor and two technical advisors: engineers who have different strengths and who all promised to respond to questions within two business days. Frances is reading and writing code in four different languages, and is able to get guidance in all of them. The other guys also have very different perspectives. Tollef has worked in several open source contexts but approaches MediaWiki's API with learner's mind. Brad has hacked on the API itself and maintains a popular Wikipedia bot that uses it. And Merlijn is a maintainer of an existing client library that lots of Wikimedians use. I bring deep knowledge of our technical community, our social norms, and project management. And I'm in charge of the daily "are you blocked?" communication so we avoid deadlocks.
- Frequent communication. Any time Frances needs substantial guidance, she can ping one of her mentors in IRC, or send us a group email. She also updates a progress report page and tells our community what she's up to via a public mailing list. We have settled into a routine where she checks in with me every weekday at a set time. We videochat three times a week via appear.in (its audio lags so we use our cell phones for audio), and use a public IRC channel the other two weekdays. We also frequently talk informally via IRC or email. She and I have each other's phone numbers in case anything is really urgent.
- Strong relationship. I met Frances before we ever thought about doing OPW together. I was able to structure the project partly to suit her strengths. We've worked together in person a few times since her project started, which gave us the chance to tell each other stories and give each other context. I've encouraged her to submit talks to relevant conferences, and given her feedback as she prepared them. Frances knows she can come to us with problems and we'll support her and figure out how to solve them. And our daily checkins aren't just about the work -- we also talk about books or silliness or food or travel or feminism or self-care tips. There's a healthy boundary there, of course, since I need to be her boss. But our rapport makes it easier for me to praise or criticize her in the way she can absorb best.
- Frances is great. I encouraged her as an applicant; from her past work and from our conversations, I inferred that she was resourceful, diligent, well-spoken, analytical, determined, helpful, and the kind of leader who values both consensus and execution. I know that many such people are currently languishing, underemployed, underappreciated. A structured apprenticeship program can work really well to help reflective learners shine.
I got to know Frances because we went to the same sci-fi convention and she gave me a tour of the makerspace she cofounded. Remember that just next to the open source community, in adjacent spaces like fandom, activism, and education, are thousands of amazing, skilled and underemployed people who are one apprenticeship away from being your next Most Valuable Player.
- Scope small & cuttable. Frances didn't plan to make one big monolithic thing; we planned for her to make a bunch of individual things, only one of which (the "gold standard" by which we judge API client libraries) needed to happen before the others. This came in very handy. We hadn't budgeted time for Frances to attend three conferences during the summer, and of course some programming bits took longer than we'd expected. When we needed to adjust the schedule, we decided it was okay for her to evaluate eight libraries in four languages, rather than eleven in five languages. The feature she's writing may spill a few days over past the formal end of her internship and we're staying aware of that.
- Metacognition. As Jefferson said, "If men were angels, we would have no need of government." But we're flawed, and so we have to keep up the discipline of metacognition, of figuring out what we are bad at and how to get better. I asked Frances to self-assess her learning styles and have used that information to give her resources and tasks that will suit her. Early in the internship I messed up and suggested a very broad, ill-defined miniproject as a way to learn more about the MediaWiki API; since then I've learned better what to suggest as an initial discovery approach. Halfway into the internship we realized we weren't meeting enough, so we started the daily videochat-or-IRC appointment. I have let Frances know that I can be a bad correspondent so it's fine to nag me, to remind me that she's blocked on something, to ask other mentors for help. And so on. We've learned along the way, about each other and about ourselves. My mom says, "teaching is learning twice," and she's right.
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.
# (1) 10 Aug 2014, 07:34PM: Resources For Starting Your Own Thing:
I've had two different conversations recently with feminist women who want to start their own tech startups. Even though I have never done that, it turns out that I had things to tell them that they did not already know! NON-ORDERED LIST TIME!
I'm sure this is as incomplete as "Here Are Some Grants You Could Apply For" was. Also, as I mentioned, I totally have not done this and websearching around for startup advice from founders will get you a zillion interesting results, and if they contradict me then you should probably believe them instead.
- If you're thinking of starting your own company or nonprofit, check out the books at Anti 9-to-5 Guide (thanks for the rec, Fureigh) and the resources Kronda Adair mentioned at her Open Source Bridge talk "Stop Crying in the Bathroom and Start Your Own Business". If you're specifically thinking about a for-profit product-or-service startup: my friend Rachel Chalmers, a venture capitalist (someone who invests early money into a startup), wrote about why you should be wary of venture capital(ists). You're welcome to reach out to her to pitch your idea. Also read the cautionary words about investor storytime in "The Internet with a Human Face", and some thoughts about less efficient startups.
- If you want to start your organization in order to cause change in the world, have a theory of change. I love that Open Tech Fund tells you what their theory of change is (see the last sentence in their funding model). The Ada Initiative's change strategy is in its FAQ. Here's a sample exercise you can do, courtesy of Wikimedia Foundation's Learning and Evaluation team.
- Remember that you could be a social enterprise -- a mission-driven for-profit company, like Etsy, Growstuff, or Dreamwidth. (Skud, founder of Growstuff, maintains the Growstuff blog and you can, for instance, see a snapshot of its finances.)
- If you are specifically looking to start an organization as a means of increasing diversity in tech, read "Trying to get paid to work on diversity in tech? Read this" and "The Ada Initiative Founders on Funding Activism for Women in Open Source". Consider your theory of change, and look at who's already trying out the method you're thinking about (bootcamps, apprenticeships, online tools, recruiting/hiring arbitrage, after-school programs, training allies, convenings, curriculum change...). And -- as Jessica McKellar entreats us -- once you start trying things, measure what you're doing, so you know whether you're effective.
- If you want to make a product or service that specifically helps people who have mental illnesses, you're not alone -- for instance, at least one person is "Designing an ADHD-friendly to-do app" -- and there's certainly a market there -- for instance, the Compassionate Language Learner, who has depression, uses Lift. And there's a curb cut principle here, where making something that helps reduce anxiety and enhance executive function can help a lot of users, neurodiverse and neurotypical both. One could look at Graze, ZocDoc, and Fancy Hands as models here.
- If you need to improve your own programming skills in order to found effectively, check out the Felder-Silverman learning styles and use your self-assessment to help you choose useful learning activities. If you're trying to choose and stick with learning projects, you may find my piece "From 'sit still' to 'scratch your own itch'" helpful. Maybe you'd enjoy making funny or feminist things. If you've already programmed a bit before, try porting something you already made into a new language. Go ahead and copy existing things that you think are cool, e.g., Hollaback, Listen to Wikipedia. This is learning time and it is OK not to make new things the world needs. You can learn and then build the thing you want to exist. (This helps us see why games are popular learning projects: you have a ready-made specification to work from, so you don't need to decide "how should this work?", and they make people feel happy.)
- If you have not done executive-y things before, check out my Open Source Bridge talk "Learn Tech Management In 45 Minutes".
- If you have, without knowing it, been waiting for someone to give you permission to do this: I give you permission. (No kidding, I said this to one of them, because she realized she needed it. Permission granted!)
# 23 Jul 2014, 10:01AM: What Is To Be Done?:
When I worked at Salon.com I got to work with Scott Rosenberg. I never reported to him and barely got to collaborate with him directly, more's the pity, but I did get to witness him in meetings. He would listen for most of the meeting, then speak up, insightfully and concisely summarize others' viewpoints, and then say what he thought and why. (He was also the first person at Salon to predict that Schwarzenegger would win the governorship.) And he wrote Dreaming in Code, a book I frequently recommend to help non-programmers understand the infelicities and headiness of software engineering.
These days Scott is targeting his insight into our industry, long-term perspective, experience as theater critic and tech manager, and delightful prose at the issue of "being ourselves in a post-social world" -- or, life after Facebook. I love how he's working on it and I look forward to watching his work. And hey, I am still not on Facebook, so maybe I already live in Scott Rosenberg's future! I AM A TIME TRAVELER. WHOOOO. SPOOKY NOISES.
Anyway. Thinking about Scott's influence on me makes me think about management. I'm taking a break from formal management at my job right now, but I'm still on the board of directors of the Ada Initiative, and besides that there's my interest in influencing my communities informally. As Frances Hocutt put it,
when I talk about leadership and influence I am not talking about coercion or manipulation. I define influence as the ability to connect with others, and discover that their goals are also your goals.
(Hocutt and Rosenberg are also both saying interesting things about authenticity and leadership, by the way, in case you want to go read about that on their sites.)
A few years ago, I read the Project Gutenberg text of Florence Nightingale's On Nursing, and I thoroughly recommend it. Nightingale focuses on executive energy, attention, and putting the proper processes into place such that patients (employees) have the resources and quiet they need to get better (do their work). Once you get to a certain administrative level, instead of solving problems ad hoc you have to think strategically. As she puts it, a manager's question is, "How can I provide for this right thing to be always done?" You know, scaling.
One of the best thinkers on that particular question as it applies to the software industry is Camille Fournier, whom I hope to work with someday. She writes interestingly about autonomy, mastery, and introspection, making it easy for people to do the right thing, choosing to ignore easy problems, becoming the boss, and growing new engineering leaders. You can also watch or read her !!Con talk "How To Stay In Love With Programming" on the !!Con site.
And in case you want to play a game, try the manual text adventure "Choose Your Own Troika Program For Greece" (author's note) by Daniel Davies.
One of the motivations for the post was a discussion I had with @PabloK on twitter about the Greek negotiations, in which he said, rather succinctly, that the purpose of protest was to change the space of what was politically possible. I think this is a crucial point; although it is important to make a good faith attempt to understand the constraints that people work under (which is why I wrote the post), it is equally important not to regard those constraints as necessarily being imposed by Ultimate Reality.
(As long as I'm mentioning wacky takes on European financial crises I have to link to John Finnemore's analogy monologue.)
I am being super digressive today, thinking about the fact that I'm grateful for the chorus of thinkers and activists who sing so I can go take a breath, thinking about my choice to manage and lead adults and to probably not bear or raise children, thinking about how it gets tiringly abstract sometimes to always be setting up leveragable scalable systems, and thinking about the joy of mentoring future leaders. If I had to try to tie all of this together, I would say that the power of leadership is the power to change the constraints that people work under. And that I see a lot of my friends not-very-willingly constrained by Facebook, and I'm looking forward to seeing that go away.
# (6) 14 Jul 2014, 11:24AM: 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.
- 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é.)
- 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)
- 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.
Edited on 6 Feb 2018 to add: I said some of this stuff better in my post today, The Ambition Taboo As Dark Matter.
# (2) 23 Apr 2014, 04:54PM: 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.
# 06 Jan 2014, 07:37PM: 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.
# 02 Nov 2013, 02:25PM: Emboss:
I recently came across Lauren Bacon's "The Accidental Boss: Making Peace with Power" again, and it reminded me: We don't talk enough about power. We don't talk enough about how hard it is to transition from individual contributor to manager, and to delegate the tasks that you really love, that might even constitute your identity. We talk about delegating, but we don't talk enough about the inner emotional security you need to develop in order to hire and trust people smarter than you.
And we certainly don't talk enough about the necessary skill of constructively managing your anger in the workplace.
We say that anger is poison or that anger is righteousness, but have you had a role model who showed you how to manage your anger? Have you learned when to wait before sending that pissed-off email? How did you learn that?
And those intersect, of course. Sometimes I disagree with my subordinates or my superiors, but I believe I always work with them constructively and I don't let my mood get in the way of hashing out the issues and finding a decision. But what if I'm wrong?
Argh gender. We women get disproportionately less training, formal and informal, in handling personal power and in using anger. And I have to do that double-checking multiple times a week, predicting how others would react to any given reveal of my power or anger.
Jono Bacon publicizes the risk of burnout. Those middle stages include substantial anger, irritability, and anxiety. How do you know when your anger is a healthy, legitimate response to a wrong? How do you know when your anger is getting in your way?
(Oh, and those of us who grew up with parents who didn't deal with their own anger responsibly have even more trouble with this. Double argh.)
What do we have? Where are we talking about these things? Sunday sermons, "Chain of Command" and "Lower Decks" from Star Trek: The Next Generation, the odd thoughtful BDSM-related blog post or fanfic, a few essays about Obama's leadership style, leadership coaching seminars, activist retreats? Is this what the Harvard Business Review is for?
I have gotten into the habit of reviewing my anger with a trusted colleague or friend. "Foo happened and bar happened and he said x and I said y... I feel frustrated/resentful/unappreciated/patronized, and basically angry, and it's distracting me... what do you think? am I being reasonable?" Advantages: fewer damaging blowups. Disadvantages: sometimes I lose the opportunity to respond to a problem in the moment, and when I do respond, the other person thinks I'm holding a grudge.
Skill acquisition is hard, yo.
# 09 Nov 2012, 08:36AM: Mission:
I decided to transcribe the speech in which newly reelected US President Barack Obama thanks his campaign staff and reflects on his own experience as a community organizer. I hope this helps nonnative English speakers and the Deaf. (.srt file available for download even! I'm not sure how to tell YouTube to use this instead of its superlatively awful automatic captions.) But I really just wanted to get his words right so I could talk about them.
In June 2008, the new Democratic Presidential candidate, Barack Obama, gave a speech to his campaign staff that Leonard and I watched. I was a project manager at a webdev shop, thinking about what "politics" means and admiring Obama's campaign for its "transparency, trust, boldness, and long-term investment and empowerment of non-bosses". I thought about Obama's viral leadership model: he doesn't just want to be that kind of leader, he wants to make you that kind of leader. And I loved the audacity of only doing effective things.
Four years and change later, I've become more and more like his audience, and like him. I became a community organizer, albeit in open source rather than electoral politics. I work to train contributors to mentor each other and to run events. I argue that we shouldn't do ineffective things, even if they're tradition. And in his 2008 speech, when he says:
Now everybody is counting on you, not just me. I know that's a heavy weight. But also what a magnificent position to find yourself in, where the whole country is counting on you to change it, for the better. Those moments don't come around very often....
he might as well be talking to me, about the stress and the opportunity of working for Wikimedia.
"And the work that I did in those communities changed me much more than I changed the communities," Obama says. That is the virtue of doing this work not in pairs, as missionaries do, but alone, as Genly Ai does in Ursula K. Le Guin's The Left Hand of Darkness:
Alone, I cannot change your world. But I can be changed by it. Alone, I must listen, as well as speak. Alone, the relationship I finally make, if I make one, is not impersonal and not only political: it is individual; it is personal, it is both more and less than political. Not We and They; not I and It; but I and Thou.
I also loved his explanation, "And it taught me something about how I handled disappointment, and what it meant to work hard on a common endeavor. And I grew up. I became a man during that process." What a tremendously hopeful conception of masculinity and adulthood, to be say that "I became a man" by growing a disciplined empathy.
And here my thoughts go in too many directions to capture: how contributors get ignored if we aren't The Right Sort, and how we fight back (and David Brooks, surprisingly, captures a useful nuance); you can no longer diss women and get away scot-free in national US politics; maturity, sustainability, and self-soothing; "I am here because of Ashley."
But back to the thank-you speech: let me excerpt the most moving part.
You know, I try to picture myself when I was your age. And I first moved to Chicago at the age of 25, and I had this vague inkling
about making a difference. I didn't really know how to do it. I didn't have a structure. And there wasn't a presidential campaign at the time that I could attach myself to. Well, Reagan had just been reelected.
And was incredibly popular. And so I, I came to Chicago knowing that somehow, I wanted to make sure that my life attached itself to helping kids get a great education, or helping people living in, in poverty to get decent jobs and be able to work and have dignity. To make sure that people didn't have to go to the emergency room to get healthcare. And, you know, I ended up being a community organizer out in the South Side of Chicago with some, a group of churches who were willing to hire me. And I didn't know at all what I was doing....
And so when I come here and I look at all of you, what comes to mind is: it's not that you guys actually remind me of myself. It's the fact that you are so much better than I was.
In so many ways! You're, you're smarter and you're better organized. And, you, uh, you're more effective. And so I'm absolutely confident that all of you are gonna do just amazing things in your lives. And you'll be what Bobby Kennedy called the ripples of hope that come out when you throw a stone in a lake. That's gonna be you!
You know, I'm just looking around the room and I'm thinking: wherever you guys end up ... you're just gonna do great things!
And, and that's why even before last night's results, I felt that the work that I had done, um, in running for office, had come full circle.
[Obama's voice chokes with emotion]
Because what you guys have done means that the work that I'm doing is important. And I'm really proud of that. I'm really proud of all of you.
[Obama tears up]
For the first time, I saw famously cool, self-controlled Barack Obama tear up. This is what gets at him, in his bones: empowerment.
I should check in again in another four years, and ask how I'm measuring up.
# 19 Jun 2012, 06:17AM: Conference Seasoning:
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."
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.
# (1) 19 Jun 2012, 05:54AM: 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.
# (5) 23 May 2012, 11:45PM: 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.
# 26 Mar 2012, 05:53PM: Announcements and Reading:
I'll be keynoting the Open Source Bridge conference this year (late June, Portland, Oregon, USA). It's an honor to be asked to give a keynote address to this exciting and inspiring conference.
"<body> <img> -- the anxiety of learning and how I am beating it" is my newest post at Geek Feminism.
Enjoyed in the last several weeks: Naomi Kritzer's "Scrap Dragon," a short story in the January/February issue of The Magazine of Fantasy and Science Fiction. "Recognizing Gabe: un cuento de hadas," a short story in Strange Horizons by Alberto Yáñez. "Things Greater than Love" by Kate Bachus, another story in Strange Horizons. Past Lies, a graphic novel by Christina Weir, Christopher Mitten, and Nunzio DeFilippis.
# (1) 10 Jul 2011, 01:22AM: "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.
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.
# (2) 29 Jun 2011, 07:01PM: Open Source Bridge 2011:
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.
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:
DNSSEC @ Mozilla -- way over my head, which is fine.
- 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.
- Drupal Distributions, an Open Source Product Model made me think about the danger of fragmenting sub-communities within a larger FLOSS community.
- 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.
- Selena 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."
- 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.
- 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.
- "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
- 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.
- "Inviting Contributors to Open Source Webdev through Virtualization" by Les Orchard told me that not just Dreamwidth, not just Wikimedia, but also Bugzilla and addons.mozilla.org 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.)
# 23 Jun 2011, 10:12AM: 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.
# (1) 09 Jun 2011, 02:04PM: Portland and San Francisco Travel This Month:
I'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!
# (5) 03 May 2011, 10:40AM: New Job, New Email Address:
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 QuestionCopyright.org (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.
# (1) 01 May 2011, 09:45PM: 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:
# 11 Apr 2011, 03:38PM: 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:
- Corralled answers for journalists. A few journalists asked me followup questions after the press release, so I got answers from other GNOME people, wrote answers, replied to the reporters via email and phone, and put these answers on the wiki (Talking Points).
- Managed the GNOME Journal launch. Nagged the last few authors, edited articles for content and style, uploaded them, fought with Textpattern, continued planning to move us to WordPress, and sent out the publication announcement. I'd still love for people to continue publicizing this, since there are many interesting nuggets that I haven't seen picked up by the larger press.
- (Started planning the next two issues of GNOME Journal, including hopes for a 3.x roadmap article in case anyone wants to write it.)
- Did a teensy bit of web testing and feedback regarding gnome3.org. Great job!
- Went to the Linux Foundation Collaboration Summit. There, I talked up GNOME 3 to reporters and other interested Linux folks, and made contact with some KDE people and started talking about publicity for the upcoming desktop summit. It sounds like we should be working to drum up attendance now, by planning special events, trumpeting rare speakers, and publicizing the unique benefits of attending GUADEC & the Desktop Summit.
- Attended the marketing/PR training at the Linux Foundation Collaboration Summit (thanks for setting it up, Dave!). I sure did learn a lot, from strategies for resource-constrained projects (build relationships with five key reporters) to tips for being interviewed. I will link to Cloer's slides and add my notes when she puts them up.
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. :-)
# (3) 01 Apr 2011, 04:21PM: 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 gnome.org 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!
# (2) 22 Mar 2011, 08:45PM: 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.
I 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.
# (5) 02 Mar 2011, 04:54AM: 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.
# (1) 26 Feb 2011, 09:52AM: 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.
QuestionCopyright.org 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!
# (3) 01 Feb 2011, 08:47AM: When Am I Ever Going To Have To Use This?:
Yesterday, while negotiating with potential clients, I used:
- You know, standard reading, writing, and interpersonal speaking skills (many courses, school newspaper, speech & debate, Academic Decathlon)
- Basic algebra to work out some price quotes (elementary school math classes)
- US and world geography (K-12, history classes)
- The wheelbarrow anecdote from Benjamin Franklin's autobiography to make a point about open source contributions as a marketing tool (eleventh grade American Literature)
- Political science concepts of authority and legitimacy, in determining a client's needs regarding open source leadership (college)
- Knowledge of Unix-style design (started in college, especially at the Open Computing Facility)
- The innovation S-curve, and cautionary tales of platforms that never got uptake from customers and vendors (master's in tech management)
All that school comes in handy sometimes!
# (7) 23 Aug 2010, 09:45PM: 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.
- Revenue. Guaranteeing a financial return. Not just cutting costs, but actually MAKING money from customers.
- 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!]
- Cutting costs. More popular in a struggling company.
- Competitive advantage -- this means the company is already behind its competitors and has lost first-mover advantage.
- 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.
# 24 Jun 2010, 03:40PM: 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.
# (1) 10 May 2010, 10:29AM: GNOME & Conference Planning & Writing:
I'm back in New York City. Big priorities this week include:
# (2) 05 Feb 2010, 11:48PM: 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.
# 22 Nov 2009, 10:29PM: Career Analysis Stuff:
You might be interested in my analysis of my career history in a longish Crooked Timber comment.
I'm very glad that I had so many different work experiences before making irrevocable choices, and that I delayed grad school till I had a specific purpose.
Tonight I thought a little about loyalty to one's workplace in a comment on Venkatesh Rao's thought-provoking business management post.
Loyalty to an organization? Identifying with an organization? For a fairly smart hard worker, who actually believes in the stated goals of the organization, it's fairly seductive, especially if they conflate their specific subcommunity with the institution as a whole.
I learned via Mel Chua that Gerald Weinberg, whose work has influenced my industry and my career profoundly, is very ill. My thoughts are with him.
# (1) 25 Sep 2009, 08:49AM: We Already Know The Title Of His Management Tips Book:
I used to watch Project Runway identifying with the contestants. Now I watch and think, "Tim Gunn is really good at phrasing criticism in a way that's likely to get across to the designer. I want to be that kind of manager."
# (1) 12 Sep 2009, 06:25PM: Wintour Guide:
I watched and enjoyed The September Issue with Elisa (who pseudoblogs as The Mad Fashionista and with whom I watch Project Runway). Some brief thoughts:
The September Issue is an office comedy ("comedy" in the sense that no one dies and the issue successfully comes out). And it's a portrait of a power couple. Editor-in-chief Anna Wintour and creative director Grace Coddington have worked together for decades, each admiring the other's talents but fairly relentless in the battle to pursue her own artistic vision. The creative tension between forward-looking Wintour and history-mining Coddington drives Vogue and the film. This film passes the Bechdel Test by leaps and bounds. It's lovely to watch unapologetically powerful women and learn how they use their power.
Coddington is marvelously resourceful in using any leverage or opportunities she finds. She gives lots of forthright-seeming interviews to the documentarians, so she gets to appear quite a lot in the film (contrast Wintour, whose famous reserve only goes away when she's at home with her daughter). Coddington asks Wintour for a larger budget for a project in front of the camera crew, and later grins that Wintour is more lenient on funds when she's on camera. And, most mischieviously, she gets the cameraman to appear in an inventive photo shoot for Vogue, and explicitly tells us that capturing and using him on film is a bit of revenge. Subverting their gaze and getting a witty, pretty spread is a nice twofer.
The film chronicles the development of the 2007 September issue of Vogue, which explains why everyone in the film is acting like the economy's fine. But even two years ago, was Vogue setting trends and making waves? Coddington credits Wintour with integrating celebrity culture into fashion culture faster than other mags did, but seventy years ago film stars' fashion choices got copycatted all over. Current events in fashion don't get discussed much, either; The September Issue doesn't mention blogs, or Project Runway, or Lucky, or counterfeit goods.
But there is a historical subtext in the film, a subtext that comes closest to the surface when Coddington stands motionless before elaborate Versailles gardens. The gardens are expensive and elaborate and required not just a wealthy patron but an entire edifice to support them (Si Newhouse is to Wintour as Wintour is to Coddington). Each photo shoot that Coddington orchestrates is as beautiful as a blossom. But any individual fashion that Coddington captures in her Vogue spreads is as ephemeral as a blossom. The gardens are still there, and still magnificent, and what are you doing that will last centuries?
Sherwood Anderson writes in Winesburg, Ohio of thoughts of mortality: "He knows that in spite of all the stout talk of his fellows he must live and die in uncertainty, a thing blown by the winds, a thing destined like corn to wilt in the sun." I reread bits of Winesburg the other day, and remembered that the really scary thing about that last image is the sun's betrayal.
Coddington calls herself a romantic. She loves old gardens and 1920s styles. And she remembers what got shot for a previous issue but didn't run, and notices when Wintour cuts a few spreads from the coming issue that represent USD$50,000 worth of work. She must know that she works for an enormous, ridiculous edifice. She must know that it's unsustainable, that her art form requires resources that only monarchies and this historically anomalous corporate media system can bring to bear. Anna and Coddington and Condé Nast are in a symbiosis to perpetuate a grand, dying art.
"High fashion" is a niche, like opera, regimented gardens, country dancing, &c., and getting niche-ier. Wintour says fashion is about what's next; does she know? The September Issue doesn't say.
# 03 Aug 2008, 10:33PM: 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!
# 30 Jul 2006, 08:30PM: 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.
# 02 Sep 2005, 11:55AM: Impulses:
What we are now learning about the devastation in the Gulf combines with a growing desire, borne of my working life, to become a manager, a good one.
You can hire me through Changeset Consulting.
This work by Sumana Harihareswara is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at firstname.lastname@example.org.