<M <Y
M>

: 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).

Getting Unstuck sampler cover

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:

  1. Assess a legacy project to decide whether you should get involved.
  2. Settle into a legacy project and become a competent and credible contributor.
  3. Take charge of a legacy project on a project, people, and financial level.
  4. Execute transformative change in a legacy project.
  5. 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:

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).

Filed under:


: Compassion Heist: I just devoured All the Young Men, a memoir by Ruth Coker Burks with Kevin Carr O'Leary. In just a few years, in 1980s and 1990s Hot Springs, Arkansas, a young single mother became the hub of a mutual aid network to help gay men dying of AIDS. You may have read a 2015 article in the Arkansas Times about her work.

In 1986, 26-year old Ruth visits a friend at the hospital when she notices that the door to one of the hospital rooms is painted red. She witnesses nurses drawing straws to see who would tend to the patient inside, all of them reluctant to enter the room. Out of impulse, Ruth herself enters the quarantined space and immediately begins to care for the young man who cries for his mother in the last moments of his life. Before she can even process what she's done, word spreads in the community that Ruth is the only person willing to help these young men afflicted by AIDS, and is called upon to nurse them.

That bit in the middle of Huckleberry Finn, where Huck tears up the letter. You know?

As she forges deep friendships with the men she helps, she works tirelessly to find them housing and jobs, even searching for funeral homes willing to take their bodies -- often in the middle of the night. She cooks meals for tens of people out of discarded food found in the dumpsters behind supermarkets, stores rare medications for her most urgent patients, teaches sex ed to drag queens after hours at secret bars, and becomes a beacon of hope to an otherwise spurned group of ailing gay men on the fringes of a deeply conservative state.

Throughout the years, Ruth defies local pastors and nurses to help the men she cares for: Paul and Billy, Angel, Chip, Todd and Luke.

This book is of course a moving story about love and care. But also it's -- as Leonard put it -- a compassion heist.

When her work with AIDS patients started, Burks was selling time-share vacation homes. And she brought that same persuasiveness, resourcefulness, and stubbornness to her volunteer work. No one willing to draw blood for tests? She learned to do it, and literally came through the back door into the government health department to drop it off for anonymous testing. She weaponized her straight-white-Southern-lady privilege whenever necessary and possible to get her guys treated fairly by landlords, doctors, and bureaucrats.

And after the federal government finally started funding work, Burks started getting pushed out. Agencies wouldn't hire her because she didn't have a college degree, and of course out of sexist discrimination as well.

I'm a little bit used to the story of scrappy activists raising money with drag shows and concerts and bake sales -- the exemplary depiction may be the film Pride, and if you haven't seen it, you're in for a treat. But the next act of the story, where institutional funders start to show up but bypass the folks on the ground -- if there are movies about that I'd like to know.

Most of All The Young Men isn't about that. It's about carework, love, witty retorts, raising a daughter with a found family of drag queens as her uncles, battling stigma and prejudice, and Burks calling on her huge network of neighbors and friends to get things done. Recommended.

Filed under:


: 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.

Getting Unstuck sampler cover, with graphic of a flowing river

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:

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!

Filed under:


: 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.

Introduction

My consultancy is Changeset Consulting.

Stories

  1. Gathering info and helping decisions:

    WisCon

    Mailman (What was new in GNU Mailman 3.0, announcement of the Mailman 3.0 release)

  2. 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)

  3. 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:

  1. Settling in (doing routine tasks that do not require much trust)
  2. Taking charge (doing things that require trust but that the group has already agreed needs to happen)
  3. Making change (modifying and adding social, digital, financial, and legal infrastructure)
  4. 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).

Conclusion

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!

Filed under:


: Gaps in Existing Guidance on Open Source & Software Management: Getting Unstuck sampler cover 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:

My competition

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

Software management

(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".)

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:

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.

Filed under:



[Main]

You can hire me through Changeset Consulting.

Creative Commons License
This work by Sumana Harihareswara is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available by emailing the author at sh@changeset.nyc.