Thread by @HeyChelseaTroy

Marco is right.

Folks do OS for a few reasons. We hyperfixate on "save the world by building an X." Which is a shame because:

1. that one has some issues we tend to gloss over
2. OS advice and expectations tend to assume that one.

Shall we go through some OS motivations?

1/

https://twitter.com/polotek/status/1459948296336670721

Note: I'm skipping "Green Box Credit" as a motivation. That's an extrinsic motivation created by employers in lieu of actual instructive hiring criterion, and its optimization is a 24h cron with an empty commit script to a public repo.

We're not counting that.

Onward.

2/

The next motivation for OS contribution is to learn.

Couple things about this one.

1. Code bootcamps and whatnot LOVE to recommend this to BEGINNERS, and it's one of the worst ideas I've heard these places consistently parrot. Here's why:

3/

Why OS contrib often sucks as a "learning opportunity" for beginners:

1. Beginners are usually learning end user app dev (bootcamps) or low level systems (CS). Popular OS projects usually aren't those—DEF not that first one. So it's high barrier to entry for beginners.

4/

Reason #2 that OS contrib often sucks as a "learning opp" for beginners:

2. A PR to an OS repo represents work for the maintainers. The less mergable-as-is, the more work it represents. Beginners tend to submit not-mergable-as-is PRs. So maintainers either have to...

5/

a) Put in a ton of work to fix the PR
b) Put in a ton of work to safeguard the OP's feelings
c) Both.

Most OS maintainers are also not exactly career diplomats either, so they might not be good at B even if they wanna do it.

Result: rough contrib experiences for beginners.

6/

HOWEVER, I have seen OS be a LOT more successful as a learning opp for people WITH experience.

1. They're more self-sufficient and require less of the original maintainers' help

2. They know How Programmers Are (TM), so a terse comment from a maintainer doesn't put them off

7/

Tips for Doing OS to Learn: Beginners

1. PRing to a popular library probably won't be a positive experience
2. Instead, make your own learning repo (or fork) and work on that
3. Reach out to seasoned folks for feedback on SPECIFIC parts of that code

I do this. It works.

8/

Here's an example of a time I did it, and literal maintainers of CPython itself pitched in to help me make my Python project more performant (y'all are the best)

https://twitter.com/HeyChelseaTroy/status/1431026306150449152

9/

Tips for Doing OS to Learn: Experienced

You are more likely ready to PR a popular or jointly-maintained library

1. Read a book about the kind of thing the project is first.
2. Talk to the maintainers about where you can help most BEFORE PRing in.

I did this w @roc_lang!

10/

OK, next reason to do OS: Try Out Your Personal Idea

This one covers a lot of the contribs Marco is talking about in that tweet above.

And it's fine! You're allowed to have your personal vision! You're allowed to want to build your cardboard fort and not let others in.

11/

This can be great for learning, too, because you're testing a hypothesis about whether something is gonna work or not.

Now, I WILL say this: if the goal is to Try Out Your Personal Idea and THEN Take The Industry By Storm...

...uh, THAT's probably not gonna happen.

12/

Here's why: most Brilliant Ideas that Take The Industry by Storm came from MANY people working together. That's even true of the ones that our rumors and history SAY came from one "inventor."

Working alone, you almost certainly miss some important considerations.

So...

13/

To Take the Industry by Storm, maybe you can START with a personal proof of concept,

but to reach scale, popularity, and maintainability, you're gonna have to NOT ONLY let other people in, BUT ALSO disproportionately value the ways they disagree with you.

14/

That's hard for anyone. For Programmers Who Think They Are Very Smart, it's often even harder.

I've seen this in companies, too. "That genius in the corner built X all by himself" almost always means there's something repellent to the rest of the team about 'that genius.'

15/

So, Tips for Trying Out Your Personal Idea:

1. Write down the hypotheses you want to test.
2. Recognize when you have confirmed or contraindicated those hypotheses.
3. Consider that a result in and of itself, regardless of what else happens with this project.

16/

Tips if your goal is actually to Take The Industry by Storm:

1. Imagine the person most often ignored by the status quo and beg/bribe those people to drive the project
2. Put more effort into community management than to writing code
3. I know you want to ignore #2. DON'T.

17/

OK, now let's talk about the one I referenced earlier, the goal of Saving the World by Building X

I've talked about the issue with this one before in this thread from last June.

I recommend really sitting with it; it's not a fun conversation.

18/

https://twitter.com/HeyChelseaTroy/status/1270024135519977474

Finally, there's Ideological Commitment to Free Software.

I mostly hear about this OS motivation now from folks who were 20somethings in the 70/80s.

Younger OS contributors are quicker with "I want to make $ from this code, or from the knowledge I get by writing it"

19/

There's historical reasons for tech's unique degree of idealism and saviorism compared to other unabashedly capitalist industries, but that's not the point of this thread.

20/

On the "free" thing: I mean, pragmatically, super hard to make that work.

I say that as a person with a business that deliberately and almost exclusively supports clients who are either grant-funded or directly supported by the community they serve.

Eventually...

21/

...someone has to sustain the project.

And if maintainers don't think about how that's gonna happen, it's easier for it to end up happening in ways orthogonal to (or even antithetical to) the project's publicly stated goals.

22/

Idealistic OS projects regularly get "sponsored" and then consumed or shut down by private companies.

That's extreme, but if a sponsor keeps you alive, you have to care what they need. Unless they're LITERALLY who you wanna serve, you can end up with some ugly tradeoffs.

23/

Those are the MAIN motivations I've seen for doing OS.

This is my Twitter account so I get to talk about MY motivations, and I'll do that now.

I've got 3.

24/

My motivations for doing OS:

1. Learn. OS projects help me do this by, effectively, holding me accountable to others for being able to execute on the things I am studying on my own.

It's harder to quit studying if 4-10 other people are expecting your PR on the subject.

25/

This happens at jobs too, but ultimately, as a pre-tech boss once sagely told me, "no one pays you to learn."

I can't get hired to jobs I don't know how to do yet. But an OS project that sees my GENERAL exp doesn't mind that I'm a beginner at their specialty.

26/

My OS Contrib motivation #2: Get paid to teach.

I reduce my rate for clients who let me live stream my work; if their code is public anyway, they're like "HELL YES"

Then I get $ to "show people how to debug" (see: fork up on camera), which tech education rarely covers.

27/

Here's where I organize those videos. My most streamed projects are an iOS app about Scottish Gaelic Phrases (evidently the foremost resource on the web for space-efficient custom wait spinners, lol) and then, of course, @the_zooniverse mobile app

28/

chelseatroy.com/category/live-…

My OS Contrib motivation #3: Make tech education more accessible.

My biggest OS project that I maintain solo is probably my interactive textbook for my Python Programming classes, which is free because forcing students to buy my book felt icky.

But then I got ambitious, so

29/

...so now the plan is to create a standalone resource that a new (or maybe even intermediate) Pythonista could use by themselves to get up to speed or learn new stuff.

Here it is. Please don't hammer me with feature requests.

30/

github.com/MPCS-51042/mat…

BONUS MOTIVATION:

OS projects often face greater support demands & community management challenges than internal repos, so code stewardship REALLY matters for them. I'd like to learn from and contribute to how they do that.

More:

30/30

chelseatroy.com/2021/01/18/avo…