<D <M <Y
Y> M> D>

: MidAmericon and Zambia: MidAmericon II, the 74th Worldcon (a long-standing yearly celebration of scifi and fantasy and the fandom thereof) has just released its programming schedule. I'm participating in several program items. All of the following take place August 17-21, 2016, at the Kansas City Convention Center in Kansas City, MO.

  1. Panelist, "The Interstices of Historical and Fanfiction", Wednesday Aug 17, 7pm-8pm, KCCC 2204
  2. Panelist, "The Imaginary Book Club", Thursday Aug 18, 11am-noon, KCCC 2502A
  3. Panelist, "Bad Boy Woobie", Thursday Aug 18, 1pm-2pm, KCCC 2204
  4. "Comedy Tonight!" (I'll perform about 30 minutes of stand-up comedy during this three-person showcase), Thursday Aug 18, 7pm-8:30pm, KCCC 3501B
  5. Panelist, "The New Space Opera Golden Age on the Screen", Friday Aug 19, 10am-11am, KCCC 2503B
  6. Auctioneer for Tiptree Award Auction, Friday Aug 19, noon-1pm, KCCC Flexible Activities Space
  7. Panelist, "The Art and Science of Fiction Translation", Friday Aug 19, 2pm-3pm, KCCC 3501F
  8. Panelist, "Comics Confrontational! Social Issues in Recent Comics", Saturday Aug 20, 10am-11am, KCCC 2206
  9. Panelist, "Representation in Comic Books: From Absences to Affirmatives", Saturday Aug 20, 1pm-2pm, KCCC 3501B

At this Worldcon I will finally get to meet, for the first time, Ken Liu, whom Leonard and I published in Thoughtcrime Experiments seven years ago. I predict I will meet him because he and I will both serve on that scifi translation panel, and I'll see friends Elise Matthesen and Teresa Nielsen Hayden because we're also on sessions together. Will I get to see other friends? Only future Sumana knows.

Then, in late August and early September, I'm visiting family abroad. Specifically: my sister Nandini, an extremely impressive person, works for the United Nations Capital Development Fund as a Digital Finance Country Technical Specialist. In case you haven't heard of UNCDF:

UNCDF is the UN's capital investment agency for the world's 48 least developed countries. It creates new opportunities for poor people and small businesses by increasing access to microfinance and investment capital. UNCDF focuses on Africa and the poorest countries of Asia, with a special commitment to countries emerging from conflict or crisis.

Getting this job meant that she and my brother-in-law moved to Zambia. I will make my first ever trip to Africa in order to see them! And I'll get to see Victoria Falls. If you know someone in Lusaka you think I should meet, especially anyone interested in open source software, please let me know!


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Filed under:



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