Open Source Comics: Resources, Collaboration, and Funding for making Comics for Open Source Projects

[MarsBarLee (Mars Lee)]

Hi all!

Following up with the wonderful discussion the August OSD call, I’m creating this thread to collate that discussion and how we can create comics for open source projects.

My Background and Comics

Hi, I’m Mars! I’m a Technical Illustrator at Quansight. Earlier this year, I made and distributed comics at SciPy 2022! (a conference about “Scientific Python”: the programming language Python, specifically open source projects in science, math and research)

Here’s a link to a digital, flip-able version of the comic!

SciPy Comics | PDF to Flipbook

We distributed 300 print copies to 500 in-person conference attendees and a digital version as well!

Here’s a 3 minute slide deck of my experience!

• Tabled and handed out the comics for 3 days
• Gave a 5 minute Lightning Talk focused on the power of design, story and comics. That these technical problems always have a human core
• Joined the conference sprint: Add alt text to Scientific Python projects!

As you can see, I love comics!

Why Comics?

If you’re in the OSD forum, I think you’re already sold on comics. But if you’re not, here’s some reasons:

• ‘A picture’s worth a thousand words’. If you ever doodled a flowchart while explaining a concept, then you intuitively knew that
• Easy to read and pick up, introducing people to new concepts without needing to read a full page of documentation

How others could replicate my work: Open Sourcing and Funding It!

One key discussion from the OSD call was how we could get more people to make comics about open source!

While I love the work I did, I recognize its privileges’ and limitations:

• I made the comic while having a salaried position in a company. Thus I was compensated for my time.
  • These comics took over 100 hours of work (12 pages x 5 hours each page from sketch to final render, brainstorming, pitching, script-writing, editing, meetings with team, printing, etc)
  • The prototype took 10 hours and I did it myself, off work hours
• My team were fellow employees, who were also compensated
• My conference ticket, lodging and printing were compensated by my employer

Thus, if we want more people making comics in open-source, we need to:

• share the knowledge
• equip non-designers with design skills to make their own comics
• equip designers with supportive communities and non-design skills such as pitching and budgeting
• show the value of small-scale: that a small doodle is just as powerful as a printed 12 page comic
• fund and support design

In some spaces, this is about reducing the ‘bus factor’. Thankfully, I’m not the only one making ‘tech comics’! Here are some people who do as well:

• wizardzines
• Bubblesort zines
• Erika Heidi

The key question for me is, how can we get more people involved? ‘Comics about open source’ is still pretty niche.

Creating a Central Resource?

I would like to create a central resource that shows people how to make comics about open source projects! And that people can add to!

For now, I’ll edit this thread post with links and suggestions from the August OSD call.

In the future, having a more formal place would be nice. I’m particularly inspired by the Turing Way (and not just because they got cool illustrations).

In that case, a site could be set up with Read the Docs. Or simpler, like a static site generator, Nikola. Or even simpler, a shared Google Doc.

How this Resource is Different: Not Repeating
This resource isn’t Comic Making 101. Nor does it repeat what the OSD community already knows about design.

Rather, the value would be in this intersection of comics and open source concerns, such as:

• Fitting in and Expanding a Project’s Documentation
• How to Pitch at Community Calls
• Funding and Sustainability
• Licenses

I would also like to write blog posts about my personal experience making comics for SciPy 2022. Lots of practical advice and funny anecdotes of that experience worth sharing . There’s a list of potential blog topics below.

Call to Action

If you have a resource or topic you would like added, just post below! I’ll add them to the list of resources.

Thank you for the discussion at the August OSD call! @Erioldoesdesign , @juhan , @jan @SaptakS , @simonv3 (let me know if anyone’s Discourse handle is incorrect)

---

Resources and Examples

‘Own Your Health Data’ Comic

GoInvo: Open Source Visualizations on Health and the Healthcare Industry

Academic Paper showing Value of Comics: Medical Graphic Narratives to Improve Patient Comprehension and Periprocedural Anxiety…

Comicgen: Character Creator, from easy-to-use drop down options

Early Sketches and Script for the ‘SciPy Accessibility Comic’, showing timeline and comments

---

Future Discussion or Blog Topics
Some topics are more for designers, some are for non-designers (developers, marketing, etc)

• How Comics could Get Someone to RTFM/Read the Docs
• Where Comics Fit into Documentation, using the Diátaxis framework
• Publish Yourself: Digital Options such as imgur, heyzine and Github
• Getting your Printed Comics out there! How to table at conferences and zinefairs
• Printing Advice: DIY photocopiers, print-shops, turnaround times and more!
• Pitching Comics: How to sell the value of design to non-designers and Where to Do it (Hint: Community Calls)
• Securing Funding: Who wants to fund our niche intersection? More than you think!
• Illustration as Alternative Mediums for Learning: for newcomers and visual learners
• How to make Comics Accessible for the Disabled Community: Alt Text and learning from web-based accessibility
• Building Your Team: Editor, Muse, Manager, and You
• How Technical Illustrators can work hand-in-hand with Technical Writers
• Licenses: Yes, just photocopy it! But wait- do I need a license? Zine Culture X Open Source Licenses
• Lessons from Fandom and DIY Zines
• How to Invite People into the Design Process: Brainstorming, Script-Writing and Sketching Together
• Translating Technical Concepts to Visual Metaphors: Communicating to the Domain Expert without Misrepresentation (but keeping the fun)
• Illustrating Thorny Issues Without Prickling Too much: Governance Models, Moderation and other topics, such as dealing with a difficult community member
• Presenting Your First Draft and Getting The Feedback You want
• Panel by Panel: The Value of Sequential Arts and Time in Explaining Technical Concepts
• What Flowchart Makers are Missing: Storytelling and the Human Core

[jdittrich (Jdittrich (he|they))]

Thanks!

• I would be particularly interested in “Translating Technical Concepts to Visual Metaphors” and “Illustrating Thorny Issues” (And/or maybe even a “sociological comic” about open source culture and its social practices and problems? @Erioldoesdesign ?)
• Felienne Hermans uses “xkcd style” comics in her slides and her book and does research on how people think about code and how they learn programming.
• I really like printed zines. If you have a printer (and the brochure setting in its driver), you only need a brochure stapler (10-15€) and you can create your own little A5-sized zines.

[MarsBarLee (Mars Lee)]

There’s so much potential in a “sociological comic”! I attend two community calls for an open source project: 1) NumPy community calls and 2) NumPy Documentation community calls. I take the meeting notes, so I document the conversations.

One re-occurring topic is sustainability: “How do get more contributors to become maintainers?”, with variations such as:

• “how do we move first-time contributors into regular contributors?”
• “how we can we reward first-time PR reviewers, not just first-time contributors?”
• “when is the right time to set up someone for peer-programming or mentoring? how do we know someone is worth investing in but not pressure them into a role they’re not read for either?”

Here’s an example of how these conversations flow. It’s about giving merge rights for the NumPy codebase, but the larger conversation seems to be about cultural standards.

• “How can we give people more merge rights?” → “Ask for merge rights and you shall receive” → “But people don’t even know they can ask” → “Those who are ready/know enough will know” → “But that limits our pool. that’s the problem and why we don’t have enough maintainers” → “We can’t pre-emptively give this power. People ready for merge rights should already know to ask.”

There’s such an interesting push and pull. On the surface is about code but deeper down is simply human: how we organize ourselves, specifically in the context of open source.

I can imagine a comic that illustrates why each side feels this way, to reduce the tension of “you don’t understand me”. One side is volunteer maintainers protecting their limited bandwidth, another side is asking how we can sustain and expand.

I’m sure you @jdittrich and Eriol have research showing the “archetypes” in how communities govern themselves, maintain, etc, haha. These are patterns that people have studided. Have a microscopic view (discussion on merge rights) and pull out to a macroscopic view (volunteer-led OS tends to do X…).

The thorny part of course, haha, is depicting these complex conversations. The meeting notes are public in a Github repository, but reasonably there’s hesitation in highlighting these conversations, even if the intended end product is sympathetic, educational and not naming names.

I feel close enough to these community members to check-in if and how they would like to be depicted. In a way, the topic of “Translating Technical Concepts to Visual Metaphors” feels easy in comparison haha

• Thank you for linking to Felienne Hermans research! Taking a look at it now.
• Now that there’s more in-person conferences, I think more print zines of open source would be awesome! In terms of printing, I’ve used a home printer, an office printer and print shop. Some printed at home, some printed at the conference location. The ability to print an little A5 zine anywhere is like it’s own sneakernet.

[MarsBarLee (Mars Lee)]

Here’s a sketch I made of the discussion of contributor → maintainer, from the NumPy community call on August 31, 2022.

Here are meeting notes on this conversation, in the NumPy Github repo.

I wrote the script. I tried to address some concerns I’ve heard about illustrating or codifying an informally defined path. That’s you can’t skip ahead, it’s moderated but also very community-focused. Parts such as “with mentorship”, “not a quick or easy path, but one worth having” and “community will be there with you every step of the way”

I made this after the call, so I’ll bring it for feedback on the next NumPy community call.

[jdittrich (Jdittrich (he|they))]

@MarsBarLee

I can imagine a comic that illustrates why each side feels this way, to reduce the tension of “you don’t understand me”.

I think this would be an excellent use of an “sociological comic”: People™ usually think that others in their place, placed under the same circumstances, would act the same way.

@MarsBarLee

The thorny part of course, haha, is depicting these complex conversations.

What I could imagine doing is taking several examples and create a new synthetic example that demonstrates the pattern – which could also be member checked.

[jdittrich (Jdittrich (he|they))]

@MarsBarLee

“How can we give people more merge rights?” → “Ask for merge rights and you shall receive” → “But people don’t even know they can ask” → “Those who are ready/know enough will know” → “But that limits our pool. that’s the problem and why we don’t have enough maintainers” → “We can’t pre-emptively give this power. People ready for merge rights should already know to ask.”

Oh yes! I guess that “meritocracy” in many open source projects hinges very often on, well, the collection of merit. So the visible of merit (like merge rights) ought not be given to people who do not have yet the merit and cultural alignment (which includes “knowing that you should ask”).

It makes sense insofar though as onboarding new people (particularly if they are not yet familiar with other open source projects) needs a great deal of care for them. However, the question of care for people is tricky, as it does not reflect many values of FOSS communities: It is not reflected in code, it does not scale and you won’t be celebrated for your expertise.

[jdittrich (Jdittrich (he|they))]

I gave it a try and started some sketches based on my article on the differences between open source and design-culture.

I find it relatively difficult to find good characters and I have trouble drawing dynamic poses (I wanted characters to push and pull elements, point etc.)

What I found helpful was playing with open peeps for creating characters and basic facial expressions. The poses are somewhat limited though, so I will need to draw my own ones. I will probably do this by loading similar elements into a drawing/painting app (krita or the like), though I currently mainly use pen and paper to try out ideas.

[MarsBarLee (Mars Lee)]

Hi @jdittrich! These comics are awesome!!! (three exclamation points because its worth that many). I love your article and it’s something I’ve referenced in an OSD call earlier this year and internally at my employer’s techshares. Having a comic version is cool. It’s making me smile right now, these 6 powerful panels. Even “basic” stuff, like gesture (raised hand), speech bubbles, smaller people representing users, is so valuable.

Open Peeps and Blush is a great way to start layout and ideas. @jan recommended something similar, comicgen.

These tools are a fancy version of a vision board. Or AI-generated illustrations, such as DALL-E. They let anyone take the first step, define their vision.

The second step is refining it. So an illustrator can help refine, do the dynamic poses you want, such as push and pulling elements.

To me, “drawing skills” is the least important and least scalable part about comics. Looking nice is the last part, but the part that catches attention haha

I think the limitation for both tools is that the next step requires having a editor, eg Krita you mentioned, or Inkscape.

One way I’ve been working around that limitation is by hosting Design Jams. I hosted one recently, the NumPy Newcomers Design Jam. I use Google Jamboard, which doesn’t require an account (unlike popular design tools like Figma).

• Link to Slides
• Link to Jamboard

By hosting a live session, I can explain and demonstrate the design process. Showing people a collaborative document and letting them stick sticky notes wherever was both fun and liberating. So what if we had Open Peep figures on a Jamboard? Just drag and drop!

[ei8fdb (Bernard Tyers)]

@MarsBarLee I’ve finally found the contract comics I mentioned to you on September’s meeting. It’s an article from a legal industry (legal industry!) magazine.

(You can download them from my cloud-thing also.)

I hope they’re of interest.

[Erioldoesdesign (Eriol Fox)]

Code of Courage: A Comic About Digital Security for Activists – PEASEC –...