Ten years of PyLadies São Paulo em português

I had the privilege to give the closing keynote at the conference PyLadies São Paulo had on 6 September. I wish I could have been there in person, but I gave it remotely. Even so, I couldn’t miss the chance to practice my Portuguese, which I did with the help of Fernanda, my beloved Portuguese teacher.

In it I ruminate over some of the challenges and threats organizations like PyLadies face today, as well as some thoughts about the strengths that will help them meet the future. Spoiler alert: the people of Brazil in general and the Brazilian Python community and PyLadies communities in particular have been some of the most welcoming and affectionate folks I’ve met, and I did my best to let them know that the feeling was mutual.

So if you want to practice your Portuguese (or Google translate) skills, the text (em português) of that talk can be found at https://naomiceder.tech/posts/pyladies_sao_paulo/

30 year old Latin texts re-discovered

They may not date back to Pompeii, but rather surprisingly I managed to get a version of PageMaker running in a virtual machine and exported to PDF a pair of Latin textbooks I had self published in 1993.

One was a collection of Catullus and Horace with notes used to prepare for the old AP Latin exam, and the other is set of readings and grammar review for third year Latin.

It’s quite possible that given the current hostility toward humanities education, they will be entirely ignored, but maybe future scholar (with a PDF reader) will discover them.

Whatever future awaits them they are now released to the public under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 license and can be found at https://naomiceder.tech/posts/latin_texts/

Ear training, the saga continues

When I get a chance I’m going to write up where I am currently with ear training. The short version is that I was going about it all wrong, and I now think I’m at least doing things a bit less wrong. ;-)

Correcting and learning from mistakes

Not having had much experience with recognizing intervals, I decided to keep things simple and start with just 3 intervals, the major third, the perfect fifth, and a perfect octave. Since I was making plenty of mistakes, I started thinking about how to correct those mistakes. For a while I tried repeating an interval until I got it right, but considering the limited choices (major third, perfect fifth, and octave) and the fact that I was showing the right answer after the fact, that wasn't much help.

I was also finding that I was struggling most with telling a perfect fifth and an octave apart. I have no idea if this is a common issue, but it seemed to me that they are both similarly consonant, and unless I was careful (and all too often even if I was careful) they sounded similar to me.

My first approach was to reduce the possible choices to just those two. I could always add thirds back in later, but first I wanted to get past the fifth/octave confusion. Next I tried creating a cell that picked notes at random and then played the possible intervals. Warming up with this approach seemed to improve performance at least for a session immediately after that.

I also tried playing both possible intervals (in order) immediately before playing the test interval. This turned out to be too easy - I went from around ⅔ correct to getting all of them right. I know, big surprise, right? So I found it hard to believe that that approach was actually helping me learn anything.

That said, I do wonder if that approach might be worth trying. but only playing the samples randomly, only part of the time, and progressively less often. Another option might be to play only one reference tone, say the octave or fifth, to help set the stage.

Finally, I decided to add code to review the mistakes. Since I was already collecting the incorrect answers, along with the notes and correct interval, it was easy enough to instead add a review of wrong answers after the main run was finished. This randomly selected items from the list of incorrect answers, only removing them when they were answered correctly. After trying it a time or two, I decided to double the list of incorrect choices (incorrect = incorrect * 2), just to give me extra practice with the trouble spots.

Improving feedback

In addition to handling the errors, I had found the feedback was not clear enough. If I made and error, I wanted it to be a little bit obnoxious about it. (As you might guess I'm not totally against negative feedback).

I decided that playing an irritating noise might be a good way to handle indicate an incorrect guess. I wasn't able to get the Jupyter Audio component to play a sound automatically during a loop (although it would as the main code in a cell), so instead I went with the playback3 library and a gong .wav file I found in a quick search. This, along with some clearer messages and a count of the total attempts in a session, gave me much better feedback.

The current code

The actual code was this:

choice = ""
correct = []
incorrect = []
total_tries = 0
while choice.lower() != 'q':
    total_tries += 1
    test_interval = random.choice(intervals)
    base_note_name = random.choice(chromatic_guitar[:-12])
    base_note = note.Note(base_note_name)

    test_stream = stream.Stream([base_note, 
                                 base_note.transpose(test_interval)])

    test_stream.show("midi")
    choice = input("interval: ")
    clear_output()
    if choice == test_interval:
        correct.append(choice)
        print(f"{choice} is correct\n")

    elif choice.lower() == 'q':
        total_tries -= 1
        break
    else:
        playsound("gong.wav")
        incorrect.append((test_interval, base_note, choice, base_note.transpose(test_interval)))
        print(f"{choice} is incorrect\n")

    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(f"{base_note.name},  {base_note.transpose(test_interval).name} --> {test_interval}, {choice}")

incorrect = incorrect *2
while incorrect:
    total_tries += 1
    print(f"Reviewing {len(incorrect)} missed items")
    test_item = random.choice(incorrect)
    test_stream = stream.Stream([
                                      test_item[1], 
                                      test_item[3],
                                ]
                               )
    test_stream.show("midi")
    choice = input("interval: ")
    clear_output()
    if choice == test_item[0]:
        correct.append(choice)
        incorrect.remove(test_item)
        print(f"{choice} is correct\n")
    elif choice.lower() == 'q':
        total_tries -= 1
        break
    else:
        playsound("gong.wav")
        print(f"{choice} is incorrect\n")
    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(f"{test_item[1].name},  {test_item[3].name} --> {test_item[0]}, {choice}")

percentage = float(len(correct)/total_tries * 100.0 if total_tries else 0)
print(f"{total_tries} tries for {len(correct) } intervals correct = {percentage:02.1f}%\n")

if not incorrect:
    print("All errors fixed")
else:
    print(f"{len(incorrect)} errors not fixed")

Future options

This is still pretty simple minded. There is no attempt to track results or progress over time and no analysis of the types of errors which could shape remedial exercises. Both of those would require adding a SQLite database, which would be easy enough to do.

Beyond that, with a database, I could also add spaced repetition to the sessions, refreshing old work why moving on to new items. I had included that in my first notes on the project, but I'm not sure if I'll feel the need to implement it. If I do, I guess that would lead to a part 3 of the series.

Results

But even with it still being simple, I now had\ something that was starting to work as I'd hoped. I can fire up this notebook every day, work through 3 or 4 runs of 30 choices and get extra practice with my mistakes.

I've been pretty consistent in practicing every day, which I think is at least partly due to the fact that it's my code and I had to understand the problem in order to create it.

So far I've been happy with the results. After a few days of practice, I can now more reliably tell my fifths from my octaves, I've even added both major and minor thirds back in, and am surprised at how much easier those are for me.

One piece has been missing, however. That is ear training. I hear and learn melodies and rhythms just fine, but I've been missing the ability to recognize intervals by ear. Is that a perfect 5th? Or is it a minor 3rd? Maybe an octave? My guesses were not nearly as reliable as I thought they should be.

The answer, of course, is ear training, basically practicing identifying intervals until one's recognition improves. There are, of course, tons of apps and web sites that will help you do that for free.

That would be the easy way, or at least the obvious way. But I've tried them (very briefly) before and they never engaged me. In fact, they just seemed frustrating. After decades of teaching, I know that frustrating = un-motivating = doomed to fail.

So my solution was to create my own ear training program. The process is inherently more interesting (at least for me). You have to think a bit about how to go about the training, you have to think about the structure of a program to do that, and you have to write the code. And you have to TEST the code, which in itself assures more time using it.

I should also note that so far, this entire project has been free from AI. Yes, I know I could get a chatbot to generate the code, the approach, the design, or even a whole ear training website. If I were mainly interested in using AI to generate code, then maybe that would make sense. But again, that would diminish, or even eliminate, my involvement and motivation in the whole process. In the end, it would be no better, if not worse, than just using one of the many pre-existing apps.

So here begins my ear training journey, coded the old fashioned way.

Basic app idea

The basic idea is just play intervals, try to guess them, and evaluate whether the guess is right or wrong. So that means that the pseudocode at a high level might be something like:

loop:
    Get a note name at random from list of notes
    Get an interval name at random from list of intervals
    Create first note from note name
    Create second note of interval by transposing the  first note by the interval
    Play the notes 
    Get the user's response
    Check response against actual interval name

The implementation of that basic idea was the next step.

Platform

I was pretty clear from the beginning that I would use a Jupyter notebook for this experiment, since I had no need for a standalone app, and the convenience of a notebook is hard to beat. For generating the sounds, Music21 seemed right for me, since it can generate midi sounds and can manipulate and transpose notes, making it easy to create pairs of sounds separated by arbitrary intervals.

I knew I needed to install music21 so once I had a notebook ready (I used pyenv to create a Python 3.13 environment for the project), I installed music21 from within my notebook:

%pip install music21

The code, first iteration

The first thing I needed to do was load dependencies:

from music21 import * # import everything from music21
​
import random
​
from IPython.display import Audio # load the Jupyter audio widget
from IPython.display import clear_output # used to clear a cell

I needed music21 of course, the random library for selecitng notes and intervals, and from the IPython.display library I would need both the audio player and the clear_output function to clear the output after each guess.

Since I'm primarily a guitarist, I wanted to use the range of sounds available on the guitar. I had already experimented with music21 a couple of years ago, so I had the code to define the notes of the fretboard ready to go:

chromatic_guitar = ["E3", "F3", "F#3", "G3", "G#3", "A3", "A#3", "B3", 
       "C4", "C#4", "D4", "D#4", "E4", "F4", "F#4", "G4", "G#4", "A4", 
       "A#4", "B4", "C5", "C#5", "D5", "D#5", "E5", "F5", "F#5", "G5",
       "G#5", "A5", "A#5", "B5", "C6", "C#6", "D6", "D#6", "E6", "F6", 
       "F#6", "G6", "G#6", "A6", "A#6", "B6"]

Transposing is pretty easy to do with music21, you can either use a number of steps or a string with an interval name (in either case, the default is to transpose up, and prepending a "-" will transpose down.) For example:

from music21.note import Note
​
Note("E").transpose(1)    # E to F
Note("E").transpose(-1)    # E to Eb
Note("E").transpose("m3")    # E to G (minor third)

Using a list of interval names is more useful for the current purpose than using integers so I created a list of intervals, but commented out all but the perfect 5th and perfect octave to make it a bit easier on my untrained ears:

intervals = [
    # "m2",    #minor 2nd
    # "M2",    #major 2nd
    # "m3",    #minor 3rd
    # "M3",    #major 3rd
    # "P4",    #perfect 4th
    # "D5",    #aug 4th/dim 5th
    "P5",    #perfect 5th 
    # "m6",    #minor 6th 
    # "M6",    #major 6th
    # "m7",    #minor 7th 
    # "M7",    #major 7th 
    "P8",    #perfect octave

After those three cells of preliminaries, the basic app looked like this:

Disclaimer: of course my actual first iteration was messier than this, I've cleaned up the false starts, errors, and extraneous bits.

# initialize
choice = ""
correct = []
incorrect = []
​
# loop
while choice.lower() != "q":
    test_interval = random.choice(intervals)
    base_note_name = random.choice(chromatic_guitar[:-12])
    base_note = note.Note(base_note_name)
    test_stream = stream.Stream([base_note, base_note.transpose(test_interval)])
​
    test_stream.show("midi")
    choice = input("interval: ")
    clear_output()
    if choice == test_interval:
        correct.append(choice)
​
    elif choice.lower() == "q":
        break
    else:
        incorrect.append(
            (test_interval, base_note, choice, base_note.transpose(test_interval))
        )
​
    print(f"{len(correct)}/{len(correct)+len(incorrect)}")
    print(
        f"{base_note.name},  {base_note.transpose(test_interval).name} --> {test_interval}, {choice}"
    )

Reflection

This was enough to get me started, and I soon discovered that I was every bit as bad at telling perfect fifths and octaves apart as I'd feared, and I struggled to call 2/3 of the pairs correctly.

That pushed me back into teacher mode, and I started thinking about how I could modify the code to help me learn. As I thought about it, there were several things that were not optimal.

First of all, the feedback on whether a guess was right or wrong was only indicated by the change in the counter of correct over total attempts. More obvious and forceful feedback would be helpful,

Secondly, there was no way to learn from the mistakes, other than displaying the incorrect list. In fact, I'd decided to use lists for correct and incorrect, rather than just counters, because I was pretty sure I'd want to do something to help learn from the mistakes.

I'll talk about what I did to address these issues (and why) in the next post, coming soon.

Changes

It’s now been about two years since I last posted a community story here. There are at least a couple of reasons for that. One is that there didn’t seem to be that much interest in the content, which I suppose is hardly surprising. The folks in the trenches doing community work may not have the time or energy to read the reflections of someone no longer engaged in that work. I got the impression that on both sides, the juice wasn’t worth the squeeze.

The other reason was that my attention ended up being diverted. In late 2023 I started working with my publisher on a fourth edition of The Quick Python Book, and as that project got moving I found that I had less time and energy for writing about community, and less inclination to do any additional writing at all.

That wasn’t my only diversion, either. I had also started spending more time on classical guitar, as well as music theory and a little composing, so between that and book project most of my spare time was occupied for the next year and a half.

At this point that new edition has been out for a couple of months, and with a bit more time, I’ve had the urge to write a bit more, both about my explorations in music and a some more memoir-ish essays.

A more general space

The issue was that this publication had been created and presented as being only stories and reflections on open source communities, so it seemed a bit unfair to the subscribers to suddenly start posting things about music.

I started to create a different publication for the music stuff, but then considered that there were various things I might want to publish. And I kind of wanted to keep using the same subdomain, which luckily was not subject specific. I realized that perhaps the lesson in this situation was that it was better have a general space, and create specialized sections as needed. I always have tended to more a lumper than splitter.

A new section for Community Stories

So that’s what I’ve done. The community stories have been moved to a section named exactly that. If that was your only interest I’d recommend just unsubscribing, in any case that content will remain accessible. But while I don’t rule it out, I’m not planning on more posts on that theme in the foreseeable future, so you’re unlikely to miss anything.

On the other hand, if you’re curious about what else I might be up to (and I can honestly see no reason why you might be) then feel free to stick around. Be warned, a couple of posts about ear training (and a bit of Python) are coming up next.

But I wanted to share my first big post in English, Spanish, and Portuguese. While it’s something I’ve shared before via other platforms, from what I can see it’s still a theme that needs discussion.

Versions in Spanish and Portuguese were given at PyCon Latam 2022, 2022-08-27

I don't usually post the text of talks I've given, but I thought I'd make an exception for this one. This started out as a love letter to the Python community, but ended up with a bit of what I suppose you could call parental concern.

Delivered as the closing keynote of PyCon 2022, Salt Lake City, Utah, 2022-05-01

Good afternoon. I am honored and delighted to be here. Before I say anything else I'd like to note that this is our 20th PyCon, yes, this is number 20, and my 20th PyCon as well, and I like to give my deepest thanks to the organizers, the staff, the volunteers, and of course to all of you, for making it such a joyful return to the world. Thank you all.

I've called this "A Time of Gifts," which is inspired by a little gem of a travel memoir by Patrick Leigh Fermor, who in the early 1930's, after being thrown out of his last year of British public school for not taking it seriously enough, decided to walk from the Netherlands up the Rhine, across Europe, down the Danube and ultimately to Istanbul.1

It took him a couple of years, and the focus of the book is not so much the places and sights he visited, nor the historic events unfolding around him (he crossed Germany and Austria as the Nazis were coming to power, but seems to hardly notice). Rather Fermor is interested in the people he met along the way - boatmen and truck drivers, farmers and shopkeepers, even an occasional aristocrat, whose gifts of food, shelter, and companionship helped sustain him along the way.

For me, and maybe for many of you, my time in this community has been my time of gifts, gifts that have sustained me in many ways on my journey over the past 20 years to various continents, across two genders, through different stages of my life. So that led me to think about how we value and share the gifts of our community and how people have compared open source communities like the Python community to a gift economy.

Here at PyCon I overheard someone say, "In Python people know how open source works." Maybe. But I wonder if that understanding is really the same for everyone. There are a lot of ways to look at communities, and I expect that there will be various different opinions. But I do think it's important for communities to think about and articulate their principles, and I want to present a way of thinking about our community that makes sense to me. Maybe at least it will start some discussion.

I want to be clear that what I'm about to say is purely my own opinion - I stepped away from the PSF board nearly 2 years ago, so please don't blame any of them.

I would argue that, as a community organized around an open source language and ecosystem, we have a gift orientation. The thumbnail definition of this orientation is that people contribute what they can when they can, and in turn share the resources and help contributed by others in the community.2

This style of gift giving or mutual contribution is what we see in our Python communities - some people are contributing code, others documentation, still others the labor to hold community events. All of these gifts are freely given and everyone enjoys the benefits. Right? Sort of like a utopian anarcho-syndicalist commune, or like what the animals had on Animal Farm until the pigs turned into totalitarian dictators.

And I think for many of us who love this community, this is the narrative we turn to, particularly in misty nostalgic moments, which at least old-timers like me experience at every PyCon. But in those moments we tend to forget that things are never quite that simple, that perfect, or that idyllic. As Python, our community, our projects, and our gatherings have grown, things are not so clear. In fact, a lot of people are questioning whether this model of open source powered by gifts is still sustainable.

I suppose part of the problem is that the open source world in general and Python in particular have been almost too successful. Even as we've grown in every aspect, the number of users and their demands has grown exponentially faster. How can such relatively tiny groups of volunteers keep a community and a language used by millions going?

It's easy to find examples of things that go wrong. One issue is burnout on the part of the volunteers who make it work. Many times I've seen what I call "shooting stars", people who burst onto the scene and start contributing to the community, often in multiple ways, showing superhuman amounts of energy and enthusiasm. It seems that only months after their first events, they are organizing other events, teaching courses, contributing code, and more. These newcomers are so successful, so eager to help, that we, as a community, happily give them more and more to do, to the point that old timers like me start wondering, "how can anyone possibly do all of that?"

The answer usually is that they can't, at least not for very long. In those cases, we'll start to notice that they're looking tired, that the enthusiasm is fading even as the workload continues to go up. I've had them take me aside and quietly ask me how to deal with the stress, how to keep all the balls in the air… and when I tell them that the answer is to do less, they never seem to accept it. Oh, you can tell that they'd love to, but by now they don't have time. They have an event to organize, a review or blog post to edit, code to write, planning calls to join.

And after a few months, or a couple of years, maybe, they fade away. Emails go unanswered, deadlines slip, pull requests are ignored, calls are missed, and so on. The demands of all that they were doing, for free, as volunteers, combined with demands of work, the needs of family, etc, have literally sucked all of the energy out of them. The tank is empty and they have no more to give, and the relationship between them and the community is damaged, often irreparably.

I've also seen people who've started slower, and built on their work over the years until they have become key developers, or maintainers, or key community organizers. They've been doing what they do for many years now, usually getting more complaints than praise, and they feel that their work is being taken for granted. In many cases I think they have too much invested emotionally to walk away, but they're tired, and they're wondering how much longer they can hold on.

Sometimes those leaders have given so much more than anyone else that they end up running the project alone. They hold all the credentials, and whenever something needs to be done, everything goes through them. When encouraged to share the load, they tend to explain that they can handle it just fine, and, besides, it's more work to train new people than it is to do the work. Or maybe they feel that they just don't have the knowledge or the time to onboard new people.

On the other side are the people who are eager to join a coding project or community effort and to help out, but who end up being turned away. I've often see people whose sincere, even eager, offers of help end up ignored for a variety of reasons: no one has time to onboard them, the project that they're interested in has enough people involved (they think), they happen to be asking in the wrong place, they're trying to come in at too advanced a level, or any number of things.

If they are trying to do something that they aren't ready for yet, they can be directed towards more appropriate contributions. But often it seems to me that they just fall through the cracks. And in those cases each time they try to get involved and somehow get turned away they are less likely to try again, and we end up losing them.

The end result is that our projects and our community initiatives are at risk of dying as people burn out and are not replaced. So it happens that we often find open source projects abandoned, with unanswered issues, ignored PR's, and out of date dependencies… or initiatives with silent mailing lists, ghost town slacks, and so on. Occasionally one might get revived, but most are simply left behind.

Some even see this as just the way that open source projects work. I was reading an article about the sustainability of open source a couple of weeks ago and a developer/maintainer of several JavaScript projects characterized open source as "a model that relies on people giving more than they can for very little or nothing in return, and hoping that there will be someone to take over the mantle when the previous person burns out."3

That description of how open source works tells me that if we are in fact a gift giving culture (and I believe we are) things are going wrong. We have people giving more than they can sustain and others who are able (barely) to sustain what they give, but feel that they aren't receiving anything in return. I'm sure that feeling is made even worse by seeing companies use their work in place of systems that used to cost hundreds of thousands of dollars, without acknowledgement, and certainly without giving back even a tiny fraction of the money that they are now saving.

And then there are others who feel that their gifts are being rejected. This last is also serious - in a gift giving culture refusing someone's gift is an insult, it's a way of saying you don't want them in the community. So it's no wonder sometimes we struggle to find new people to take over projects.

So clearly there are challenges we face as an open source community. The question is what do we do about it? What can we do? To my mind the first step is to understand what's going on and what motivations and values are driving people's behavior.

The way you think about something, the narrative you tell yourself, has an impact on how you deal with it, and some ways of thinking about a problem can actually keep you from fixing it. I know from personal experience that sometimes changing, or at least clarifying, your narrative can be an important first step in dealing with a situation better.

So what does drive communities like ours? Why are we here at a conference like this where there is so much talk about community? 20 years ago the most popular explanation, popularized in things like The Cathedral and the Bazaar, was that open source was driven by self interest. Enlightened self interest to a degree, since in practical terms you were more likely to get what you wanted if you were agreeable, but still just self interest. People worked only on what interested them or benefited them, and beyond that the only other motivation was the ego boost you could get from reflecting that you were the one to solve the problem, and everyone interested in the project would know it. In fact even if you were to do something nice, something altruistic, without that ego boost as payback, that was only because you could then get the ego boost of thinking about what a noble person you were. In other words, it was self interest all the way down, no matter what you did.44

Along with this was the belief that enough genially selfish people working to scratch only their particular itches and to boost their own egos would somehow combine to produce the best of all possible worlds for everyone. As you may notice, this view doesn't have room or any notion of community, service, or altruism.

If that's the view you have of how the open source world works, then there is no problem with any of the examples I mentioned above. Rapid burnout and departure? Well, the level of their interest no longer was high enough for them to continue. Or maybe they just didn't achieve enough ego boosts. Either way, no problem. Exhausted volunteers? If they're doing what they want, they'll continue, and when the rewards aren't great enough they'll quit, that's the way it works. Abandoned projects or communities? Well that's what happens when there isn't enough interest. Better learn to deal with it. And those wannabe volunteers, who feel turned away? They must not want it badly enough, or maybe they're just not smart enough or pushy enough to elbow their way in.

Looking back, some of the stuff written 20 years ago along these lines comes off as an adolescent mix of Ayn Rand and liberal capitalism, and it seems mercifully to have fallen out of favor. Not that I can claim the moral high ground. Back in the day, most of us didn't really question notions like these, even though in practice most people actually behaved differently - they didn't actually put ego boosts and self interest ahead of all else.

I suppose we all benefited in some ways from our participation, but there were too many people doing too many generous and altruistic things for self interest to be the only thing, or even the main thing, driving us. But if you'd asked, that's how a lot of us would have explained how open source works.

To my mind that narrative of self interest was damaging to open source communities in general and to the Python community in particular. It incentivizes cowboy coding, flame wars, and fragmentation and discourages collaboration, inclusion, and community building. It's something that we are still struggling to get past 20 years later.

In fact Brett's famous phrase (which I have borrowed so many times), "I came for the language, but I stayed for community" very neatly sums up the way that many of us from the old days have changed our view of what matters in this world of open source and Python.

So that brings me back to the notion of gift giving as essential to our community. Again, if we think of hunter-gatherers, one of the classic examples of a gift culture, if a hunter makes a kill they share the meat with everyone. Sure, they want to eat, so there is an element of self interest in what they do, but they also share with the community. Interestingly in some Inuit cultures it's considered an insult to thank the hunter, since that would imply that they're doing something special. It's not special, it's just what you do.

True, we're not hunter gatherers, but I would argue that this pattern appeals to most of us, to most humans, actually. If you look at how people behave in our community, it's not hard to see the same ethos at work. People who contribute code do so because they can, and because it improves things for everyone. Certainly sometimes the code they give addresses a personal need, but many times it doesn't. Likewise people on the board and event organizers give a lot of labor that doesn't benefit them personally.

In turn, we can (or should be able to) count on sharing the benefits of the community. In addition to the software, it might be support and friendship, or maybe education and skills, or contacts and an increased professional network. I know I've experienced all of those, from being offered a book deal, to making so many friends in different countries, that it has driven my language learning the past few years, to the PyCon 9 years ago when my father died early on Sunday morning, and that evening several people made sure to sit with me so I wouldn't have to be alone.

The interesting thing for me about cultures that rely on gifts is that the process is so vague and messy. There's really no way to determine, say, that sharing one deer is exactly equivalent to, say, a certain number of fish, or apples, or whatever. Likewise, there's also no way to determine that 10 code patches equals one conference talk equals 3 board meetings, or whatever it might be. There's really no way to keep exact tit for tat accounts - what we can all count on is when someone is able, they will make a contribution that all can share. And in turn we will contribute what and when we can.

This messiness is not a bug, it's a feature - not knowing the timing nor the precise value of the contributions actually works to bring people together, since no one can ever say for sure that they are exactly even with anybody else. Instead there is a realization that everyone's fortunes are entangled, that we're all in this together. In other words, mutual contributions, this giving of gifts, is what helps bring people together and create community.

For me, articulating gift giving as what drives our culture, what creates our community, leads me to a couple of things that I think we can do better and that we need to be aware of if we want to preserve our Python community, and if we want it to continue to grow and flourish.

On the individual level. I think that if we consider everyone around us to be contributing to the best of their abilities, to be giving their gifts to the community, we will treat them (and ourselves) differently than if we believe that we're all out for our own self interest and don't really owe anyone a thing.

I would say that understanding that we are all benefiting from the contributions of others makes it easier to appreciate that work, the gifts they are giving. Hopefully it will also prompt us to show that appreciation, something that so many volunteers receive far too little of. And it should also make us a little less critical of others, since we understand that their contribution is a gift, freely given, not an obligation nor a transaction.

As for those shooting stars who rapidly burn themselves out, maybe reflecting on gift giving will help remind them that there is no need for any of us to give more than what we can, that what we can offer at any time is enough, and that in turn we all also will need to receive gifts from others. And maybe, I hope, some of us who've been around will be more inclined to give people who are over committing the gift of reminding them of that.

The mindset that we're a gift giving community may also help us to share the load more, to respect the gifts that others offer, and to give the gift of allowing others to take up some of the tasks we've done.

As I said earlier, rejecting someone's contribution shows a lack of respect - by rejecting their gift we are saying that we don't want them to be part of our community. Keeping that in mind, we need to be sure that there are ways for new and different people to contribute, and we need to give the gift of mentoring and guiding those people.

A part of this is that we also need to hand off leadership generously, give the gift of sharing positions of leadership. This gift benefits the giver as well as the receiver. I'm pretty sure that one reason I've been able to stay an active and involved part of our community across 20 years has been that I have had a deliberate policy to hand off the leadership of any project I've ended up leading to new people after 3-5 years.

In fact, the time to start thinking about and training your successor is as soon as you become a leader. It's not easy at first, it feels like a bit of a loss, but it helps new people grow and keeps the old-timers fresh by letting them do new things. I recommend it highly.

The other area where I think a sense of clarity about what makes our community work is vital is when it comes to money. So far I've deliberately not mentioned the dominant form we have of sharing resources - a market economy with exchanges based on money.

The thing about money, with its tendency towards exact transactions, exactly the opposite of the messiness of gifts, is that it works against connection and community. If you give me something worth $2.52 and I give you $2.52, we both know we're exactly even and the transaction is done. There's no need to continue the relationship. Transactions don't build community.

For that reason, particularly as a community, we need to be very thoughtful about how we deal with money. I'm not naive - in this world we pretty much all need money and I can testify that it's better to have a bit more of it than not enough of it. That's true of for us as individuals, for the PSF as an organization, and in general.

When we ask people to make helping our community a full time job, whether that's managing our community and events, or our infrastructure, or our coding process, those people deserve to be paid fairly, even generously. We also want to make our communities and events more inclusive, and many people need financial help to take part. Likewise, fostering communities around the world takes money, and in the foreseeable future for various reasons things will cost even more.

So clearly we need financial resources to help the community continue to grow and flourish. But I worry about any notion that we should make monetary exchange the driver of either the way that we get financial resources or the way we share them. What I mean by that is that as we confront the many problems around raising money and then using that money on behalf of the community, I think we need to think very carefully about it and be particularly wary of becoming "a business".

I don't have anything at all against business per se, mind you. I've made a living working for businesses and helping them succeed. And I appreciate the support businesses give to our community. But I would argue against our Python communities, the PSF being the leading example, ever acting like a business.

I've worked for several companies over 35 years, and no matter what HR or Marketing would like you to believe, being an employee is not like being in a community of shared contribution with your employer, nor is being a customer. If our contributors become employees, and our sponsors become customers, I believe our community will be diminished, if not destroyed.

I'm probably biased, but I think that so far, the PSF and the Python community have handled this well. The PSF has hired people to support the development of the community and help enable people to contribute more successfully in all areas. Money is spent supporting smaller regional and local groups and helping those communities grow and contribute and financial aid for PyCon and other major conferences also helps people with fewer resources make contributions on the global level.

Sponsorships have been developed which support the PSF generally, with few corporate strings attached. I believe this is the right strategy - as we interact with the business world, we should not try to become a business, but rather we should invite those enterprises to join in our world of free contribution. That means selling those organizations on hard to quantify, often intangible, benefits - a tough sell, but not impossible, and worth the effort.

These are just early days, however. As late stage capitalism becomes harsher, as Python's importance and big tech's power both continue to grow, the tension between a market economy and a community centered around gifts will also grow. In other words, I think it inevitable that there will be more pressure on us to abandon our culture of gifts and free contributions in favor of monetary transactions.

It could be companies trying to buy control over the language and/or community, it could be pressure to treat contributors and volunteers more like employees, or it could be any number of things, but in the coming years there will be many opportunities to sell out our community for one tempting offer or another.

If and when that happens, it will be up to us to decide whether we still want this community to be a place of free contribution and a time of gifts. I certainly know my answer.

Esta charla se presentó como keynote de PyCon Latam 2022, 2022-08-27

Versión en portugués se presentó en PyCon Latam 2022, 2022-08-27

Buenos días. Estoy encantada de hablar con ustedes hoy. Es un honor y un reto dar esta charla tanto en español como en portugués, hablando a (casi) toda América Latina.

Antes de empezar, quiero compartir mi proyecto actual. Me jubilé hace dos meses y ahora tengo tiempo para apoyar a las comunidades de Python. Quiero ofrecer mis 20 años de experiencia como regalo a cualquier comunidad de Python en todo el mundo que lo desee. Si desean consejos sobre cómo construir y administrar comunidades, mejores prácticas, códigos de conducta, inclusión, lo que sea, me encantaría ofrecerles mi consejo y ayudarlos a pensar en esos temas. Para obtener más información, visiten naomiceder.tech/community o ponganse en contacto conmigo en info@naomiceder.tech.

El título de esta charla es "Una época de regalos", inspirado por una joyita de memorias de viaje escrita por Patrick Leigh Fermor.1 En los años 30 Fermor, después de ser expulsado de su último año de "public school" por no haberlo tomado en serio lo suficientemente, decidió caminar desde Los Países Bajos por el Rin, a través de Europa, por el Danubio y finalmente a Estambul. El tardó más de un año en hacerlo, y el enfoque del libro no es los lugares que visitó, ni los eventos históricos que se desarrollaron a su alrededor (cruzó Alemania y Austria cuando los Nazis llegaron al poder, pero parece que apenas se dio cuenta). Más bien, Fermor está siempre más interesado en las personas que conoció en el camino: barqueros y camioneros, granjeros y comerciantes, incluso un aristócrata ocasional, cuyos regalos de comida, refugio y compañía lo ayudaron a mantenerse en el camino.

Para mi, tal vez para muchos de ustedes, mi tiempo en esta comunidad ha sido un época de regalos, regalos que me han sostenido de muchas maneras en mi viaje durante los últimos 20 años a través de vários continentes, a través de dos géneros y a través de mi vida. Eso me hizo pensar sobre cómo valoramos y compartimos los regalos de nuestra comunidad y cómo muchas personas han comparado las comunidades Open Source como la de Python a una economía de regalos.

En PyCon US escuché a alguien decir, "En Python la gente entiende cómo funciona Open Source." Quizás. Pero tengo dudas de que ese entendimiento sea el mismo para todos. Existen muchas formas de ver las comunidades y yo creo que tienen sus diferencias entre ellas. Pero creo que sí es importante que las comunidades piensen y articulen sus principios, y quiero presentar una forma de pensar en nuestra comunidad que tenga sentido para mí. Ojalá que inicie unas discusiones.

Yo creo (espero al menos) que lo que voy a decir tenga resonancia para la gente de América Latina, ya que muchos de ustedes han experimentado culturas de regalo similares en sus redes familiares y también han visto el daño que puede causar la explotación de recursos y comunidades por dinero.

Por supuesto, lo que voy a decir es solamente mi opinión - me jubilé de la junta directiva de la PSF hace dos años, por favor no les echen la culpa a ellos.

Yo diría que, como una comunidad centrada en un lenguaje y un ecosistema open source, tenemos una orientación de regalos. La definición breve de esta orientación es que la gente contribuye cuando y cuanto puede, y a su vez confía en recibir recursos y ayuda de otros en la comunidad cuando los necesitan.2

Estamos tan acostumbrados a los valores de una economía de mercado que nos resulta difícil entender cómo funcionan estos regalos. La entrega de regalos no es como el trueque: los regalos generalmente no se intercambian al mismo tiempo, ni el objetivo es dar regalos de valor equivalente, de modo que todos salgan "iguales".

Más bien, una persona contribuye con algo y en algún momento recibirá algo que necesita de otra persona. Nadie tiene derecho a exigir un regalo, pero aún así, se acepta que todos contribuirán como puedan. Por ejemplo, en las sociedades de cazadores-recolectores, si alguien mata o encuentra algo de comida, lo comparte con todo el grupo, sabiendo que todos los demás harǻn lo mismo.

Este estilo de dar regalos o contribuciones mutuas es lo que vemos en nuestras comunidades de Python - algunas personas están contribuyendo con código, otras con documentación, y trabajan para realizar eventos para su comunidad. Todos estos regalos se otorgan sin obligación y todos disfrutan de los beneficios, ¿no? Algo así como una comuna anarcosindicalista, o como lo que tenían los animales en Animal Farm hasta que los cerdos se convirtieron en dictadores totalitarios.

Y creo que para muchos de nosotros que amamos a esta comunidad, esta es la narrativa a la que recurrimos, particularmente en esos momentos nostálgicos que al menos los ancianos como yo experimentamos en cada PyCon.

Sin embargo en esos momentos nos olvidamos de que las cosas nunca son tan perfectas, tan sencillas o tan idílicas. Como Python, nuestra comunidad, nuestros proyectos y nuestras reuniones han crecido, la situación no es tan clara. De hecho, mucha gente tiene dudas sobre si este modelo de open source alimentado por regalos todavía sigue siendo sostenible.

Supongo que una parte del problema es que el mundo de open source en general y de Python en particular han tenido casi demasiado éxito. Si bien hemos crecido en casi todos los aspectos, el número de usuarios y sus demandas han crecido exponencialmente más rápido. ¿Cómo pueden grupos tan pequeños de voluntarios sostener una comunidad y un lenguaje utilizado por millones?

Es fácil de encontrar varios ejemplos de cosas que salen mal. Un problema es el agotamiento por parte de los voluntarios que hacen que todo funcione. Muchas veces he visto lo que llamo 'estrellas fugaces', personas que irrumpen en escena y comienzan a contribuir a la comunidad, a menudo de múltiples maneras, mostrando cantidades sobrehumanas de energía y entusiasmo. Parece que solo unos meses después de sus primeros eventos, están organizando otros eventos, impartiendo cursos, contribuyendo con código y más. Estos recién llegados son tal exitosos, tan ansiosos de ayudar, que nosotros felizmente les damos más y más que hacer, hasta el punto de que los veteranos como yo comenzamos a preguntarnos, "¿cómo es posible que alguien pueda hacer todo eso?"

La respuesta suele ser que no pueden, al menos no por mucho tiempo. En estos casos, comenzamos a notar que se ven cansados, que el entusiasmo se desvanece mientras la carga de trabajo continúa aumentando. Algunos me han llevado a un lado para preguntarme cómo lidiar con el estrés, cómo mantener todas las pelotas en el aire… y cuando les digo que la respuesta es hacer menos, nunca lo aceptan. Oh, se nota que les encantaría creerlo, pero ahora no tienen tiempo. Tienen un evento para organizar, una revisión o blog post para editar, código para escribir, o llamadas para unirse.

Y después de pocos meses, o un par de años, ellos desaparecen. Los correos quedan sin respuesta, los plazos se retrasan, las pull requests se ignoran, las llamadas se pierden, y tal. Las demandas de todo lo que estaban haciendo como voluntarios combinadas con las demandas del trabajo, las necesidades de la familia, etc, literalmente les han quitado toda la energía. El tanque está vacío y no tienen más para dar, y la relación entre ellos y la comunidad se daña, a menudo de manera irreparable.

También he visto personas que comenzaron más moderadamente, y construyeron su trabajo a lo largo de los años hasta que se convirtieron en key developers, o maintainers, o organizadores clave de la comunidad. Han estado haciendo lo que hacen durante mucho años, por lo general reciben más quejas que elogios, y sienten que su trabajo se da por sentado. En muchos casos, creo que han invertido demasiado para alejarse, pero están cansados, y se preguntan cuánto tiempo más podrían aguantar.

A veces estos líderes han dado más que nadie, y resulta que ellos manejan su proyecto solos. Poseen todas las credenciales, y cada vez que se necesita hacer algo, todo tiene que pasar por ellos. Cuando se les anima compartir la carga, tienden a explicar que pueden manejarla bien y, además, es más trabajo capacitar a nuevas personas que hagan el trabajo. O tal vez sienten que no tienen el conocimiento ni el tiempo para incorporar a nuevas personas.

Cualquiera que sea la causa, todo el tiempo también vemos personas que están ansiosas por unirse a un proyecto de código o un esfuerzo comunitario y ayudar, que terminan siendo rechazadas. Al menos una vez a la semana veo alguien cuyas ofertas de ayuda sinceras, incluso ansiosas, terminan siendo ignoradas por una variedad de razones: nadie tiene el tiempo para incorporarlos, lo que les interesa tiene suficiente gente involucrada, están preguntando en el lugar equivocado, están tratando de entrar en un nivel demasiado avanzado, o lo que sea.

Muchas veces me parece que muchos otros simplemente pasan desapercibidos. Y en estos casos, cada vez que intentan involucrarse y de alguna manera son rechazados, es menos probable que lo intenten otra vez, y terminamos perdiéndolos

El resultado es que nuestros proyectos y nuestras iniciativas comunitarias corren el riesgo de ser abandonados, cuando las personas se agotan sin ser reemplazadas. Así resulta que muchas veces nos encontramos proyectos de open source abandonados, con asuntos sin respuestas, PR's ignoradas, y dependencias desactualizadas. O iniciativas con listas de correo silenciosas, slacks vacíos,et cetera.

Algunos aún dicen que los proyectos open source simplemente funcionan así. Hace un par de meses yo estaba leyendo un artículo sobre la sostenibilidad de open source y un maintainer de varios proyectos de Javascript describió open source como "un modelo que se basa en que las personas dan más de lo que pueden por muy poco o nada a cambio, y con la esperanza de que haya alguien que se haga cargo del manto cuando la persona anterior se queme".3

Esa descripción de cómo funciona open source me dice que si de hecho somos una cultura de regalo (y yo creo que lo somos) las cosas van mal. Tenemos personas que dan más de lo que pueden sostener y otros que son capaces (apenas) de sostener lo que dan, pero sienten que no están recibiendo nada a cambio. Ese sentimiento puede empeorar al ver incluso a empresas de Fortune 100 que utilizan su trabajo en lugar de sistemas que solían costar cientos de miles de dólares en derechos de licencia, sin reconocimiento y sin devolver una pequeña fracción del dinero que están ahorrando. Y hay otros que sienten que sus regalos son rechazados. Esto último también es grave: en una cultura de regalo rechazar el regalo de alguien es un insulto, es una forma de decir que no los quieres en la comunidad.

Entonces claramente como una comunidad de open source nos enfrentamos a desafíos. La pregunta es ¿qué hacemos? ¿Qué podemos hacer? Para mí el primer paso es entender lo que está pasando y las motivaciones y valores que están impulsando el comportamiento de la gente.

La manera en la que piensas en algo, la narrativa que te dices, tiene un impacto en cómo lidias con ello, y algunas maneras de pensar en un problema pueden de hecho impedir que lo soluciones. Sé por mi experiencia personal que, a veces, cambiar o aclarar la narrativa puede ser un primer paso importante para manejar mejor una situación.

Entonces, ¿qué impulsa a comunidades como la nuestra? ¿Por qué estamos en una conferencia en que hay tanta discusión sobre la comunidad? Hace veinte años, la interpretación más popular, popularizada en cosas como La Catedral y el Bazar, era que open source estaba impulsado por el interés propio. Interés propio ilustrado hasta cierto punto, ya que en términos prácticos era más probable que obtuvieras lo que querías si eras agradable, pero era sólo interés propio. Las personas trabajaban sólo en lo que les interesaba o beneficiaba, y más allá de eso la única otra motivación era el impulso del ego que podía obtenerse al reflejar que eras tú quien había resuelto el problema, y todos los interesados en el proyecto lo sabrían. De hecho incluso si fueras a hacer algo altruista, sin el estímulo del ego, eso era sólo porque entonces podrías obtener el impulso para tu ego de pensar en lo noble que eras. En otras palabras, era el interés propio todo el camino, hicieras lo que hicieras.4

Junto con esto estaba la creencia de que suficientes personas genialmente egoístas que trabajaban por solo sus intereses particulares y para impulsar sus propios egos se combinarían de alguna manera para producir el mejor de los mundos posibles para todos. Como se puede notar, esta visión no incluye ninguna noción de comunidad, servicio o altruismo.

Si tienes esta visión de cómo funciona open source, no hay problema con ninguno de los ejemplos que he mencionado antes. ¿Agotamiento rápido y salida? Pues, el nivel del interés ya no era lo suficiente para que continuaran. O tal vez simplemente no consiguieron impulsos suficientes para sus egos. ¿Voluntarios cansados? Si están haciendo lo que quieren, continuarán, y cuando las recompensas no sean suficientes, van a salir, así funciona el mundo. ¿Proyectos y comunidades abandonados? Eso ocurre por falta de interés y debes aprender a lidiar con eso. Y ¿esos voluntarios ansiosos? Por supuesto no lo quieren lo suficiente, o quizás no son lo suficientemente inteligentes o agresivos para abrirse paso a codazos.

En retrospectiva, muchas cosas escritas hace 20 años sobre esto parecen una mezcla adolescente de Ayn Rand y el capitalismo liberal, y afortunadamente han caído en desgracia. Tampoco estoy reclamando la superioridad moral - en esa época la mayoría de nosotros no cuestionamos nociones como estas, aunque en la práctica en las comunidades en las que estábamos, la gente en general no se comportaba así: en realidad no ponía los impulsos del ego y el interés propio por encima de los demás.

Supongo que todos disfrutamos de varios beneficios de nuestra participación, pero había demasiada gente haciendo demasiadas cosas generosas y altruistas para que el interés propio fuera lo único o lo principal que nos impulsara. Pero si nos hubieras preguntado, te habríamos explicado que así es como funciona open source. Para mí, esa narrativa de interés propio perjudicó a todas las comunidades de open source: alentó la cowboy coding, las flame wars y la fragmentación mientras devaluaba la colaboración, la inclusión y la construcción de comunidades. Es algo que todavía estamos luchando por superar 20 años después.

De hecho la frase famosa de Brett Cannon, (que he usado tantas veces), "Vine por el lenguaje, pero me quedé por la comunidad" resume muy bien como muchos de nosotros hemos cambiado nuestra visión de esta comunidad.

Eso me lleva de vuelta a la noción de dar regalos como algo esencial para nuestra comunidad. Otra vez, si pensamos en los cazadores-recolectores, uno de los ejemplos clásicos de una cultura del regalo, si un cazador tiene éxito, comparte la carne con todos. Claro, el cazador quiere comer, por lo que hay un elemento de interés propio en lo que hace, pero también lo comparte con la comunidad. No es nada especial, es solo lo que se hace.

Por supuesto, no somos cazadores-recolectores, pero yo diría que este patrón nos gusta a la mayoría de nosotros, a la mayoría de humanos, de hecho. Si consideras como se comporta la gente en nuestra comunidad, no es difícil ver el mismo espíritu. Las personas que contribuyen con su código lo hacen porque pueden y porque mejoran las cosas para todos. Claro, a veces el código que ellos contribuyen responde a una necesidad personal, pero muchas veces no es así. Del mismo modo los organizadores de los eventos y las personas en la junta dan mucho trabajo que no los beneficia personalmente.

Sin embargo, podemos (o deberíamos poder) contar con compartir los beneficios de la comunidad. Puede ser apoyo y amistad, o tal vez educación y habilidades, o contactos y una mayor red profesional. Yo sé que he experimentado todo eso, desde que me ofrecieron un contrato para un libro, hasta hacer tantos amigos en diferentes países, algo que me ha animado a aprender dos idiomas en los últimos años. Recuerdo también la PyCon hace 9 años cuando mi padre murió la madrugada del domingo, y esa noche varias personas se sentaron conmigo para asegurarse de que yo no estuviera sola. Lo interesante para mí sobre las culturas de regalos es que el proceso es muy vago y desordenado. Realmente no hay forma de determinar, por ejemplo, que compartir un venado es exactamente equivalente a 15 peces, digamos, a 50 manzanas, o lo que sea. Del mismo modo, tampoco hay forma de determinar que 10 parches de código equivalen a una charla, o 3 reuniones de la junta directiva, o lo que sea. Simplemente no existe una forma de mantener las cuentas exactas: con lo que todos podemos contar es que cuando alguien puede, hace una contribución que todos podemos disfrutar. Y a su vez aportamos lo que podamos y cuando podamos

Este desorden no es un bug sino un feature - no saber ni la hora ni el valor exacto de las contribuciones en realidad funciona para unir a las personas, ya que nadie puede decir con certeza que está exactamente a la par con los demás. En cambio, se da cuenta de que las fortunas de todos están enredadas, que estamos todos juntos en esto. En otras palabras, las contribuciones mutuas, este dar regalos, es lo que ayuda a unir a la gente y crear comunidad. Para mí, articular dar regalos como lo que impulsa a nuestra cultura, lo que crea nuestra comunidad, me lleva a lo que podemos hacer mejor, y que debemos tener en cuenta si queremos preservar nuestra comunidad de Python y si queremos que siga creciendo y floreciendo.

Como individuos, creo que si consideramos que todos en la comunidad están contribuyendo lo mejor que pueden, dando sus regalos a la comunidad, los trataremos a ellos (y nosotros mismos) de manera diferente (y mejor) que si creemos que todos somos impulsados por interés propio y no le debemos nada a nadie. Yo diría que entender que todos nos beneficiamos de las contribuciones de los demás hace más fácil apreciar ese trabajo, los regalos que ellos dan. Espero que también nos impulsará mostrar nuestro aprecio, algo de lo que muchos voluntarios reciben muy poco. Y también debería hacernos un poco menos críticos con los demás, si entendemos que su contribución es un regalo, no una obligación ni una transacción.

En cuanto a esas estrellas fugaces que se agotan rápidamente, tal vez reflexionar sobre dar regalos les ayude recordar que nadie debe dar más de lo que puede, y que lo que podemos ofrecer en cualquier momento es suficiente, y a su vez, nosotros también necesitaremos recibir regalos de los demás. Y espero que nosotros veteranos seremos más inclinados a darles a las personas que se están dando demasiado el regalo de este consejo.

La mentalidad de que somos una comunidad de regalos también puede ayudarnos a compartir más la carga y a dar el regalo de permitir que otros asuman algunas de las tareas que hemos hecho. Como he dicho, rechazar la contribución de alguien muestra una falta de respeto - rechazar su regalo es decir que no queremos que sea parte de nuestra comunidad. Teniendo eso en cuenta, debemos asegurarnos de que haya formas en que las personas nuevas y diferentes puedan contribuir, y debemos dar el regalo de ser mentores y guías para esas personas.

Una parte de esto es que también debemos entregar el liderazgo con generosidad, y dar el regalo de compartir posiciones de liderazgo. Este regalo beneficia tanto al que da como al que recibe. Estoy bien segura de que una de las razones por las que he podido seguir siendo una parte activa e involucrada de nuestra comunidad durante 20 años es que he tenido una política deliberada de traspasar el liderazgo de cualquier proyecto que yo haya creado después de 3-5 años. No es fácil al principio, se siente como una pérdida, pero ayuda a crecer a la gente nueva y mantiene frescos a los veteranos. Lo recomiendo absolutamente.

Otro aspecto relacionado con lo que hace que nuestra comunidad funcione y donde creo que una gran claridad es vital, es cuando se trata de dinero. Hasta ahora deliberadamente no he mencionado la forma dominante que tenemos de compartir recursos: una economía de mercado con intercambios basados en dinero.

Lo que pasa con dinero, con su tendencia a las transacciones exactas, totalmente lo contrario del desorden de los regalos, es que va en contra de la conexión y la comunidad. Se me das algo que vale $5, y yo te doy $5, ambos sabemos que estamos exactamente a la par y la transacción está hecha. No hay necesidad de continuar la relación. Las transacciones no construyen comunidad.

Por eso, nosotros, particularmente como comunidad, debemos tener mucho cuidado acerca de cómo manejamos el dinero. No soy ingenua, en este mundo casi todos necesitamos dinero y yo puedo testificar que es mejor tener un poco más que menos.Eso es cierto tanto para individuos como para organizaciones como la PSF y en general.

Cuando les pedimos a algunas personas que hagan un trabajo de tiempo completo de ayudar a nuestra comunidad, ya sea administrando nuestra comunidad y eventos, o nuestra infraestructura, o nuestro proceso de codificación, esas personas merecen que se les pague de manera justa, incluso generosa. También queremos que nuestras comunidades y eventos sean más inclusivos, y muchas personas necesitarán ayuda financiera para participar. Del mismo modo, fomentar comunidades en todo el mundo requiere dinero, y en el futuro previsible, por diversas razones, las cosas costarán aún más.

Por supuesto necesitamos los recursos financieros para ayudar a la comunidad a seguir creciendo y prosperando. Pero me preocupa la idea de que debemos hacer que las transacciones sean lo más importante en cómo obtenemos los recursos financieros o cómo los compartimos. Lo que quiero decir es que cuando enfrentamos los desafíos de recaudar dinero y luego usarlo en nombre de la comunidad, creo que debemos pensar con mucho cuidado para no convertirnos en "un negocio".

No tengo nada en absoluto en contra de los negocios per se. Me he ganado la vida trabajando para empresas y ayudándolas a tener éxito. Pero yo estoy totalmente en contra de que nuestras comunidades de Python, siendo la PSF el ejemplo principal, actúen como un negocio. He trabajado en varias empresas durante 35 años, y no importa lo que RRHH o Marketing quieren que creas, ser un empleado no es como estar en una comunidad de dar regalos con tu empleador, ni tampoco lo es ser un cliente. Si nuestros contribuyentes se convierten en empleados y nuestros patrocinadores se convierten en clientes, nuestra comunidad se verá disminuida, si no destruida.

Probablemente estoy sesgada, pero creo que hasta ahora la PSF y la comunidad de Python han manejado esto bien. La PSF ha contratado personas para apoyar el desarrollo de la comunidad y para ayudar que la gente contribuya con más éxito en todas las áreas. El dinero se gasta apoyando grupos regionales y locales, y la ayuda financiera para PyCon y otras conferencias también ayuda a las personas con menos recursos a hacer contribuciones a nivel mundial.

Algunos patrocinios se han desarrollado de forma que respaldan a la PSF y la comunidad en general, con pocas condiciones corporativas. Creo que esta es la estrategia correcta: a medida que interactuamos con el mundo empresarial, no debemos tratar de convertirnos en un negocio, sino invitar a esas empresas a unirse a nuestro mundo de contribuciones y regalos. Para hacerlo hay que convencer a esas organizaciones de beneficios intangibles y difíciles de cuantificar. Es algo difícil, pero no imposible, y vale la pena.

Sin embargo, estos son solo los primeros días. Mientras el capitalismo se vuelve más duro, y tanto la importancia de Python como el poder de las grandes empresas de tech continúan creciendo, la tensión entre una economía de mercado y una comunidad de regalos seguirǻ creciendo. En otras palabras, creo que es inevitable que haya más presiones para que abandonemos nuestra cultura de regalos y contribuciones a favor de transacciones monetarias. Podrían ser empresas que intentan comprar el control sobre el idioma y/o la comunidad, o podría ser presión para tratar a los colaboradores y voluntarios más como empleados, o podría ser cualquier otra cosa, pero en los próximos años habrá oportunidades para vender nuestra comunidad por una o otra oferta tentadora.

Cuando eso pase, dependerá de nosotros decidir si todavía queremos ser una comunidad de regalos y contribuciones. Por mi parte, estoy segura de mi respuesta.

Muchas gracias por la atención y muchos abrazos a todos en nuestras comunidades.

Versão em espanhol foi dado em PyCon Latam 2022, 2022-08-27

Olá, sou Naomi. Estou muito feliz de falar com vocês hoje e é uma honra dar esta palestra tanto em espanhol e como em português, falando para (quase) toda a América Latina.

Antes de começar, quero compartilhar meu projeto atual. Me aposentei há dois meses e agora tenho tempo para apoiar as comunidades Python. Quero oferecer meus 20 anos de experiência como presente para qualquer comunidade Python ao redor do mundo que queira. Se você quiser conselhos sobre como construir e gerenciar comunidades, melhores práticas, códigos de conduta, inclusão, seja o que for, eu seria feliz de oferecer meus conselhos e ajudá-lo a pensar sobre essas coisas. Para obter mais informações, visite namiceder.tech/community ou entre em contato comigo em info@naomiceder.tech.

Chamei essa palestra de "Um tempo de presentes", inspirada por uma pequena joia de memórias de viagem de Patrick Leigh Fermor1, que no início da década de 1930, após ser expulso de seu último ano da public school britânica por não ser sério o suficiente, decidiu caminhar da Holanda até o Reno, através da Europa, descendo o Danúbio e finalmente chegando a Istambul. Demorou mais de um ano, e o foco do livro não são tanto os lugares e pontos turísticos que ele visitou, nem os eventos históricos que se desenrolam ao seu redor (ele atravessou a Alemanha e a Áustria quando os nazistas estavam chegando ao poder, mas ele mal percebeu isso). Em vez disso, Fermor está interessado nas pessoas que conheceu ao longo do caminho - barqueiros e motoristas de caminhão, fazendeiros e lojistas, até mesmo um aristocrata ocasional, que lhe presenteavam com comida, abrigo e companhia, o ajudando a sustentar-se ao longo do caminho.

Para mim, e talvez para muitos de vocês, meu tempo nesta comunidade foi meu tempo de presentes, presentes que me sustentaram de muitas maneiras em minha jornada nos últimos 20 anos para vários continentes, em dois gêneros, através de diferentes estágios da minha vida. Isso me levou a pensar em como valorizamos e compartilhamos os presentes de nossa comunidade e como as pessoas comparam comunidades de código aberto como a comunidade Python a uma economia de presentes.

Na PyCon US, ouvi alguém dizer: "Em Python, as pessoas sabem como o código aberto funciona". Pode ser. Mas eu me pergunto se esse entendimento é realmente o mesmo para todos. Há muitas maneiras de olhar para as comunidades, e espero que haja opiniões que divergem da minha. Mas acho importante que as comunidades articulem como pensam seus princípios, e quero apresentar uma maneira de pensar sobre nossa comunidade que faça sentido para mim. Talvez pelo menos esta palestra começarei alguma discussão.

Acho (pelo menos espero) que o que vou dizer tenha ressonância com o povo da América Latina, pois muitos de vocês experimentaram culturas de presentes em suas redes familiares e também viram os danos que a exploração de recursos e comunidades por dinheiro pode causar.

Bom. Quero deixar claro que o que vou dizer é puramente minha opinião - deixei o conselho da PSF há 2 anos, então, por favor, não culpe nenhum deles.

Eu diria que, como uma comunidade organizada em torno de uma linguagem e ecossistema de Open Source, temos uma orientação para o dom. Uma definição curta dessa orientação seria que as pessoas contribuem com o que podem quando podem e, por sua vez, contam com recursos e ajuda de outras pessoas da comunidade quando precisam.2

Estamos tão acostumados com os valores de uma economia de mercado que é difícil entender como funciona essa doação. Dar presentes não é como escambo - os presentes geralmente não são negociados ao mesmo tempo, nem é o objetivo de dar presentes de valor correspondente, para que todos saiam "iguais".

Em vez disso, uma pessoa contribui com algo e, em algum momento posterior, receberá algo de que precisa de outra pessoa. Ninguém tem o direito de exigir um presente, mas ainda assim, aceita-se que todos contribuam como puderem. Por exemplo, em sociedades de caçadores-coletores, se alguém mata ou encontra alguma comida, eles a compartilham com todo o grupo, sabendo que todos os outros farão o mesmo.

Esse estilo de doação de presentes ou contribuição mútua é o que vemos em nossas comunidades Python - algumas pessoas estão contribuindo com código, outras com documentação, outras ainda trabalham para realizar eventos da comunidade. Todos esses presentes são dados gratuitamente e todos desfrutam dos benefícios. Mais ou menos como uma comuna anarco-sindicalista utópica, ou como o que os animais tinham na Fazenda dos Bichos até os porcos se transformarem em ditadores totalitários, né?

E acho que para muitos de nós que amamos essa comunidade, essa é a narrativa para a qual nos voltamos, principalmente em momentos nostálgicos enevoados, que pelo menos veteranos como eu experimentam em todas as PyCons.

Mas nesses momentos tendemos a esquecer que as coisas nunca são tão perfeitas, tão simples, tão idílicas. À medida que o Python, nossa comunidade, nossos projetos e nossas reuniões crescem, as coisas não ficam tão claras. Na verdade, muitas pessoas estão questionando se esse modelo de Open Source alimentado por presentes ainda é sustentável.

Suponho que parte do problema é que o mundo do código aberto em geral e o Python em particular têm sido relativamente bem-sucedidos. Mesmo que tenhamos crescido em todos os aspectos, o número de usuários e suas demandas cresceram exponencialmente mais rápido. Como esses grupos relativamente pequenos de voluntários podem manter uma comunidade e uma linguagem usada por milhões?

É fácil encontrar exemplos de coisas que dão errado. Um problema é o esgotamento por parte dos voluntários que o fazem funcionar. Muitas vezes vi o que chamo de "estrelas cadentes", pessoas que entram em cena e começam a contribuir para a comunidade, muitas vezes de várias maneiras, mostrando quantidades sobre-humanas de energia e entusiasmo. Parece que apenas alguns meses após seus primeiros eventos, eles estão organizando outros eventos, ministrando cursos, contribuindo com código e muito mais. Esses recém-chegados são tão bem-sucedidos, tão ansiosos para ajudar, que nós, como comunidade, alegremente lhes damos mais e mais coisas para fazer, a ponto de veteranos como eu começarem a se perguntar: "como alguém consegue fazer tudo isso?"

A resposta geralmente é que eles não conseguem, pelo menos não por muito tempo. Nesses casos, começaremos a perceber que eles parecem cansados, que o entusiasmo está diminuindo, mesmo que a carga de trabalho continue aumentando. Alguns deles me chamavam de lado e me perguntavam baixinho como lidar com o estresse, como não deixar a peteca cair... e quando eu digo a eles que a resposta é fazer menos, eles nunca acreditam. Oh, você pode ver que eles adorariam acreditar nisso, mas agora eles não têm tempo. Eles têm um evento para organizar, uma revisão ou postagem de blog para editar, código para escrever, chamadas de planejamento para participar.

E depois de alguns meses, ou no máximo dois anos, talvez, eles desapareçam. Os e-mails não são respondidos, os prazos passam, os pull requests são ignorados, as chamadas são perdidas e assim por diante. As demandas de tudo o que eles estavam fazendo, de graça, como voluntários, combinados com as demandas de trabalho, as necessidades da família, etc, literalmente sugaram toda a energia deles. O tanque está vazio e eles não têm mais para dar, e essa relação entre eles e a comunidade é prejudicada, muitas vezes de forma irreparável.

Também vi pessoas que começaram mais devagar e construíram seu trabalho ao longo dos anos até se tornarem desenvolvedores principais, maintainers ou organizadores de comunidades importantes. Eles fazem o que fazem há muitos anos, geralmente recebendo mais reclamações do que elogios, e sentem que seu trabalho está sendo dado como certo. Em muitos casos, acho que eles investiram demais emocionalmente para ir embora, mas estão cansados e se perguntando quanto tempo mais conseguem aguentar.

Às vezes, esses líderes tinham dado mais do que qualquer outra pessoa, com o resultado de que governam o projeto sozinhos. Eles possuem todas as credenciais, e sempre que algo precisa ser feito, tudo tem que passar por eles. Quando encorajados a dividir a carga, eles tendem a explicar que podem lidar bem com isso e, além disso, dá mais trabalho treinar novas pessoas para fazer o trabalho. Ou talvez eles sintam que não têm o conhecimento ou o tempo para integrar novas pessoas.

Seja qual for a causa, o tempo todo vemos pessoas ansiosas para participar de um projeto de codificação ou esforço comunitário e ajudar, que acabam sendo rejeitadas. Pelo menos uma vez por semana vejo alguém cujas ofertas de ajuda sinceras, até mesmo ansiosas, acabam sendo ignoradas por uma variedade de razões: ou ninguém tem tempo para abordá-los, ou o projeto em que eles estão interessados já tem pessoas suficientes envolvidas, ou eles estão perguntando no lugar errado, ou eles estão tentando entrar em um nível muito avançado, ou uma série de coisas.

Se eles estão tentando fazer algo para o qual ainda não estão prontos, podem ser direcionados para contribuições mais apropriadas. Mas muitas vezes me parece que alguns deles simplesmente caem num limbo. E, nesses casos, cada vez que eles tentam se envolver e de alguma forma são rejeitados, é menos provável que tentem novamente, e acabamos perdendo-os.

O resultado é que nossos projetos e nossas iniciativas comunitárias correm o risco de serem abandonados à medida que as pessoas se esgotam e não são substituídas. Acontece que muitas vezes encontramos projetos de open source abandonados, com questões não respondidas, PR's ignorados e dependencies desatualizadas... ou iniciativas com listas de discussão silenciosas, slacks de cidades fantasmas e assim por diante. Ocasionalmente, alguém pode tentar reviver um, mas geralmente eles são simplesmente deixados para trás.

Alguns até veem isso como a forma como os projetos de código aberto são. Eu estava lendo um artigo sobre a sustentabilidade do código aberto alguns meses atrás e um desenvolvedor/maintainer de vários projetos Javascript caracterizou o código aberto como "um modelo que depende de pessoas dando mais do que podem por muito pouco ou nada em troca, e esperando que haja alguém para assumir o responsabilidade quando a pessoa anterior se esgotar."3

Essa descrição de como o código aberto funciona me diz que se somos de fato uma cultura que dá presentes (e acredito que somos), as coisas estão dando errado. Temos pessoas dando mais do que podem sustentar e outras que mal são capazes de sustentar o que dão, mas sentem que não estão recebendo nada em troca. Esse sentimento pode ser piorado ao ver até mesmo empresas da Fortune 100 usando seu trabalho no lugar de sistemas que costumavam custar centenas de milhares de dólares em taxas de licenciamento, sem reconhecimento e certamente sem devolver nem mesmo uma pequena fração do dinheiro que eles estão economizando.

E há outros que sentem que seus presentes estão sendo rejeitados. Este último também é sério - em uma cultura de presentear, recusar o presente de alguém é um insulto, é uma maneira de dizer que você não os quer na comunidade.

Então, claramente, existem desafios que enfrentamos como uma comunidade de código aberto. A questão é o que fazemos sobre isso? O que podemos fazer? Para mim, o primeiro passo é entender o que está acontecendo e quais motivações e valores estão impelindo o comportamento das pessoas.

A maneira como você pensa sobre algo, a narrativa que você conta a si mesmo, tem um impacto em como você lida com isso, e algumas maneiras de pensar sobre um problema podem realmente impedi-lo de corrigi-lo. Sei por experiência própria que, às vezes, mudar, ou pelo menos esclarecer, sua narrativa pode ser um primeiro passo importante para lidar melhor com uma situação.

Então, o que impulsiona comunidades como a nossa? Por que estamos aqui em uma conferência como esta, onde se fala tanto sobre comunidade? Há 20 anos, a interpretação mais popular, popularizada em coisas como a Catedral e o Bazar, era que o código aberto era movido pelo interesse próprio. Autointeresse esclarecido até certo ponto, uma vez que, em termos práticos, era mais provável que você conseguisse o que queria se estivesse agradável, mas ainda assim apenas interesse próprio. As pessoas trabalhavam apenas no que as interessava ou as beneficiava e, além disso, a única outra motivação era o impulso do ego que você poderia obter ao refletir que era você quem resolveria o problema, e todos os interessados no projeto saberiam disso. Na verdade, mesmo que você fizesse algo legal, algo altruísta, sem aquele impulso do ego como retorno, isso era apenas porque você, no fim das contas, estaria fazendo isso somente para obter como recompensa a sensação de "quão nobre" você está sendo. Em outras palavras, era interesse próprio até o fim, não importa o que você fizesse.4

Junto com isso estava a crença de que um número suficiente de pessoas genialmente egoístas trabalhando para satisfazer apenas seus interesses particulares e alimentar seus próprios egos se combinariam de alguma forma para produzir o melhor de todos os mundos possíveis para todos. Como você pode notar, essa visão não inclui nenhuma noção de comunidade, serviço ou altruísmo.

Se essa é a visão que você tem de como o mundo do código aberto funciona, então não há problema com nenhum dos exemplos que mencionei acima. Burnout e saída rápidas? Bem, o nível de interesse deles não era mais alto o suficiente para eles continuarem. Ou talvez eles simplesmente não tenham conseguido impulsos de ego suficientes. De qualquer forma, não há problema. Voluntários esgotados? Se eles estão fazendo o que querem, eles vão continuar, e quando as recompensas não forem grandes o suficiente eles vão desistir, é assim que funciona. Projetos ou comunidades abandonadas? Bem, isso é o que acontece quando não há interesse suficiente. Melhor aprender a lidar com isso. E aqueles aspirantes a voluntários, que se sentem rejeitados? Eles não devem querer tanto, ou talvez não sejam inteligentes o suficiente ou agressivos o suficiente para abrir caminho.

Olhando para trás, algumas das coisas escritas 20 anos atrás nesse sentido parecem uma mistura adolescente de Ayn Rand e capitalismo liberal, e parece misericordiosamente ter caído em desuso. Nem estou reivindicando o terreno moral elevado. Antigamente, a maioria de nós realmente não questionava noções como essas, embora na prática nas comunidades em que eu estava, a maioria das pessoas realmente se comportasse de maneira diferente - eles não colocavam o ego e o interesse próprio à frente de tudo.

Suponho que todos nós nos beneficiamos de alguma forma com nossa participação, mas havia pessoas demais fazendo muitas coisas generosas e altruístas para que o interesse próprio fosse a única coisa, ou mesmo a principal, que nos impulsionasse. Mas se você nos perguntasse, era assim que muitos de nós explicaríamos como o código aberto funcionava.

Na minha opinião, essa narrativa de interesse próprio foi prejudicial a todas as comunidades de open source - incentiva a cowboy coding, flame wars e fragmentação e desencoraja a colaboração, a inclusão e a construção da comunidade. É algo que ainda estamos lutando para superar 20 anos depois.

Na verdade, a famosa citação de Brett Canon (que eu quase sempre menciono) "Eu vim pela linguagem, mas fiquei pela comunidade" reflete bastante a maneira com que muitos de nós veteranos mudamos a nossa visão dessa comunidade.

Então, isso me traz de volta à noção de dar presentes como essencial para nossa comunidade. Novamente, se pensarmos em caçadores-coletores, um dos exemplos clássicos de uma cultura de dádiva é: se um caçador mata, ele compartilha a carne com todos. Claro, ele quer comer, então há um elemento de interesse próprio no que ele faz, mas ele também compartilha com a comunidade. Não é especial, é apenas o que você faz.

É verdade que não somos caçadores-coletores, mas eu diria que esse padrão atrai a maioria de nós, a maioria dos humanos, na verdade. Se você observar como as pessoas se comportam em nossa comunidade, não é difícil ver o mesmo ethos em ação. As pessoas que contribuem com código o fazem porque podem e porque isso melhora as coisas para todos. Certamente, às vezes, o código que eles fornecem atende a uma necessidade pessoal, mas muitas vezes não. Da mesma forma, os organizadores de eventos e as pessoas do conselho trabalham muito em algo que não os beneficia pessoalmente.

No entanto, podemos (ou devemos poder) contar com a partilha dos benefícios da comunidade. Pode ser apoio e amizade, ou talvez educação e habilidades, ou contatos e uma rede profissional maior. Eu sei que experimentei tudo isso, desde receber uma oferta para escrever um livro, fazer tantos amigos em diferentes países, o que impulsionou meu aprendizado de idiomas nos últimos anos, até o PyCon 9 anos atrás, quando meu pai morreu cedo no domingo de manhã, e naquela noite várias pessoas fizeram questão de sentar comigo para que eu não tivesse que ficar sozinha.

O interessante para mim sobre culturas que dependem de presentes é que o processo é muito vago e confuso. Não há realmente nenhuma maneira de determinar que compartilhar um cervo é exatamente equivalente a, digamos, 15 peixes, ou 50 maçãs, ou qualquer outra coisa. Da mesma forma, também não há como determinar que 10 patches de código equivalem a uma palestra na conferência ou que equivale a 3 reuniões do conselho, ou o que quer que seja. Não há realmente nenhuma maneira de fazer contas exatas de olho por olho - o que todos podemos contar é que quando alguém é capaz, ele fará uma contribuição que todos podem compartilhar. E, por sua vez, contribuiremos com o que e quando pudermos.

Essa confusão não é um bug, é um feature - não saber o momento nem o valor preciso das contribuições realmente funciona para unir as pessoas, já que ninguém pode dizer com certeza que elas estão exatamente empatadas com qualquer outra pessoa. Em vez disso, há uma percepção de que as fortunas de todos estão emaranhadas, que estamos todos juntos nisso. Em outras palavras, contribuições mútuas, essa doação de presentes, é o que ajuda a unir as pessoas e criar comunidade.

Para mim, articular a doação de presentes como o que impulsiona nossa cultura, o que cria nossa comunidade, me leva a pensar em algumas coisas que acho que podemos fazer melhor: precisamos estar cientes se queremos preservar nossa comunidade Python e se queremos que ela continue a crescer e florescer.

Como indivíduos, acho que se considerarmos que todos ao nosso redor estão contribuindo com o melhor de suas habilidades, dando seus dons à comunidade, nós os trataremos (e a nós mesmos) de maneira diferente do que se acreditarmos que estamos todos por nosso próprio interesse e não devemos nada a ninguém.

Eu diria que entender que todos nós estamos nos beneficiando das contribuições dos outros torna mais fácil apreciar esse trabalho, os presentes que eles estão dando. Espero que isso também nos leve a mostrar esse apreço, algo que tantos voluntários recebem muito pouco. E também deve nos tornar um pouco menos críticos em relação aos outros, pois entendemos que sua contribuição é um dom, dado gratuitamente, não uma obrigação nem uma transação.

Quanto às estrelas cadentes que se esgotam rapidamente, talvez refletir sobre a doação de presentes ajude a lembrá-las de que não há necessidade de nenhum de nós dar mais do que podemos, que o que podemos oferecer a qualquer momento é suficiente e que todos nós também precisaremos receber presentes de outros. E espero que alguns de nós que já estamos aqui por um tempo estejamos mais inclinados a dar às pessoas que estão se comprometendo demais o presente de lembrá-las disso.

A mentalidade de que somos uma comunidade que dá presentes também pode nos ajudar a compartilhar mais a carga, a respeitar os presentes que os outros oferecem e a dar o presente de permitir que outros assumam algumas das tarefas que realizamos.

Como eu disse anteriormente, rejeitar a contribuição de alguém mostra falta de respeito - ao rejeitar seu presente estamos dizendo que não queremos que ele faça parte de nossa comunidade. Tendo isso em mente, precisamos ter certeza de que existem maneiras de pessoas novas e diferentes contribuírem, e precisamos dar o presente de orientar e aconselhar essas pessoas.

Uma parte disso é que também precisamos entregar a liderança generosamente, dar o dom de compartilhar posições de liderança. Este presente beneficia tanto o doador quanto o receptor. Tenho certeza de que uma das razões pelas quais consegui permanecer uma parte ativa e envolvida em nossa comunidade ao longo de 20 anos e 2 gêneros foi que tive uma política deliberada de entregar a liderança de qualquer projeto que ajudei criar para novas pessoas após 3-5 anos. Não é fácil no começo, parece uma perda, mas ajuda novas pessoas a crescer e mantém os veteranos frescos. Eu recomendo muito.

Outro aspecto relacionado ao que faz nossa comunidade funcionar, e onde eu acho que uma grande clareza é vital, é quando se trata de dinheiro. Até agora eu deliberadamente não mencionei a forma dominante como compartilhamos recursos: uma economia de mercado com trocas baseadas em dinheiro.

Falando de dinheiro, com sua tendência a transações exatas, exatamente o oposto da bagunça dos presentes, é que ele funciona contra a conexão e a comunidade. Se você me der algo no valor de US$ 2,52 e eu lhe der US$ 2,52, ambos sabemos que estamos exatamente empatados e a transação está concluída. Não há necessidade de continuar o relacionamento. As transações não constroem a comunidade.

Por essa razão, especialmente como comunidade, precisamos ser muito cuidadosos sobre como lidamos com o dinheiro. Não sou ingênua - neste mundo, praticamente todos precisamos de dinheiro e posso testemunhar que é melhor ter um pouco mais do que menos. Isso vale tanto para nós como indivíduos, quanto para o PSF como organização e em geral. Quando pedimos às pessoas que ajudem nossa comunidade a trabalhar em tempo integral, seja gerenciando nossa comunidade e eventos, ou seja nossa infraestrutura ou nosso processo de codificação, deveríamos pagar essas pessoas de forma justa, até generosa. Também queremos tornar nossas comunidades e eventos mais inclusivos, e muitas pessoas precisarão de ajuda financeira para participar. Da mesma forma, promover comunidades em todo o mundo custa dinheiro e, no futuro próximo, por várias razões, as coisas custarão ainda mais.

Então, claramente, precisamos de recursos financeiros para ajudar a comunidade a continuar a crescer e florescer. Mas eu me preocupo com qualquer ideia de que devamos fazer da troca monetária o motor da maneira como obtemos recursos financeiros ou da maneira como os compartilhamos. O que quero dizer com isso é que, apesar de saber que enfrentaremos e lidaremos com diversos tipos de problemas em torno de arrecadar dinheiro e depois usar esse dinheiro em nome da comunidade, acho que precisamos pensar com muita prudência sobre isso e ser particularmente cautelosos para não nos tornarmos simplesmente "um negócio".

Não tenho nada contra os negócios em si, veja bem. Ganhei a vida trabalhando para empresas e ajudando-as a ter sucesso. Mas eu estaria defendendo a ideia de que nossas comunidades Python, a PSF sendo o exemplo principal, nunca deveriam agir como um negócio. Trabalhei em várias empresas ao longo de 35 anos, e não importa o que os RH ou Marketing quisessem que você acreditasse, ser um funcionário não é como estar em uma comunidade de contribuição compartilhada com seu empregador, tampouco ser um cliente. Se nossos colaboradores se tornarem funcionários e nossos patrocinadores se tornarem clientes, nossa comunidade será diminuída, se não destruída.

Provavelmente estou sendo tendenciosa, mas acho que até agora, o PSF e a comunidade Python lidaram bem com isso. O PSF contratou pessoas para apoiar o desenvolvimento da comunidade e ajudar a capacitar as pessoas a contribuir com mais sucesso em todas as áreas. O dinheiro é gasto apoiando grupos regionais e locais menores e ajudando essas comunidades a crescer e contribuir, e a ajuda financeira para PyCon e outras grandes conferências também ajuda pessoas com menos recursos a fazer contribuições em nível global.

Patrocínios foram desenvolvidos para apoiar o PSF em geral, com poucas restrições corporativas. Acredito que esta seja a estratégia certa - ao interagirmos com o mundo dos negócios, não devemos tentar nos tornar um negócio, mas sim convidar essas empresas a se juntarem ao nosso mundo de contribuição gratuita. Isso significa vender a essas organizações benefícios difíceis de quantificar, muitas vezes intangíveis - uma venda difícil, mas não impossível, e vale a pena o esforço.

Estes são apenas os primeiros dias, no entanto. À medida que o capitalismo em estágio avançado se torna mais selvagem, à medida que a importância do Python e o poder da big tech continuam a crescer, a tensão entre uma economia de mercado e uma comunidade centrada na contribuição aumentará. Em outras palavras, acho inevitável que haja mais pressão sobre nós para abandonar nossa cultura de presentes e contribuições gratuitas em favor de transações monetárias. Podem ser empresas tentando comprar o controle sobre a linguagem e/ou comunidade, pode ser a pressão para tratar os colaboradores e voluntários mais como funcionários, ou pode ser outra coisa, mas nos próximos anos haverá ofertas para vender nossa comunidade para uma proposta tentadora ou outra.

Se e quando isso acontecer, caberá a nós decidir se ainda queremos ser uma comunidade de presentes e contribuições gratuitas. Eu certamente sei minha resposta.

Muito obrigada pela atenção e muitos abraços a todos em nossas comunidades.

Anyway, as promised I’m unveiling something new - separate sections for Spanish and Portuguese versions of my posts.

That’s right, starting today, I’ll be posting versions of at least some of my posts in Spanish and Portuguese. Since these are separate sections you can choose whatever combination of languages you prefer. If, for example you choose only Spanish, then you will be notified only when something is published in the Spanish section.

To select which languages you receive, somewhat confusingly, you need to click the “unsubscribe” link at the button at the bottom of the email, which will let you change the sections you’re subscribed to (or even unsubscribe altogether, if you want to). If you have a Substack account, you can find the same controls in your account settings, I believe. Of course you can always follow the links to the Spanish and Portuguese sections. I was hoping that there would be easier ways to manage this, but it is what it is.

I have to admit that I haven’t yet worked out the details of how the logistics will work for this. I’m assuming that I’ll be able to keep up with the translations with an assist from Google translate and/or other tools, although the translated versions might be delayed a day or two after the English posts come out.

I also haven’t yet decided whether I’ll translate the old posts, not that there are so many of them. My guess is that if things are manageable, I’ll end up translating everything, but we’ll have to see.

To kick off I’ll be simultaneously posting the text of my 2022 PyCon keynote, “A time of gifts” in all three languages. Those will be published soon.

So if you know of people who might be interested in my stories about community, but would be more comfortable with Spanish or Portuguese than English, please share this with them.

Ou seja, a partir de hoje você pode assinar versões dos meus textos em espanhol e/ou português. Como são seções separadas, você pode escolher qualquer combinação de idiomas que desejar. Por exemplo, se você escolher apenas espanhol, você só receberá notificações quando algo for publicado na seção de espanhol.

Confesso que ainda não decidi todos os detalhes da logística. Suponho que consigo acompanhar as traduções com a ajuda do Google Tradutor e/ou outras ferramentas, embora as traduções provavelmente sejam publicadas um pouco depois dos originais.

Também não decidi se os posts anteriores serão traduzidos, não que sejam tantos. Acho que se as coisas estiverem sob controle, irei traduzi-las todas, mas veremos.

Para começar, publicarei simultaneamente o texto da minha Keynote da PyCon 2022, “Um tempo de presentes” (A time of gifts), em inglês, espanhol e português. Todas as três versões serão lançadas logo.

Portanto, se você conhece pessoas que preferem ler minhas histórias de comunidade em espanhol ou português, compartilhe este post com elas.

Eso es, desde hoy puedes suscribirse a versiones de mis textos en español o/y portugués. Como estas son secciones distintas puedes elegir cualquier combinación de idiomas preferidos. Por ejemplo, si elegirás solo español, vas a recibir notificaciones solo cuando algo se publica en la sección de español.

Tengo que confesar que ya no he decidido todos los detalles sobre la logística. Supongo que yo pueda mantenerme al día con las traducciones con la ayuda de Google Translate y/u otras herramientas, aunque las traducciones probablemente se publicarán un poco después de los originales.

Tampoco he decidido si se traducirán las publicaciones anteriores, no es que haya tantas. Supongo que si las cosas son manejables, voy a traducir todas, pero vamos a ver.

Para comenzar, voy a publicar simultáneamente el text de me charla principal de PyCon 2022, “Una época de regalos”, en inglés, español, y portugués. Las tres versiones se van a publicar pronto.

Entonces, si conoces a personas que preferirían leer mis historias sobre comunidades en español o en portugués, por favor comparte esto con ellos.

And there might be something worth reporting. The EuroPython has been around for over 20 years, even a bit longer than PyCon, making it the oldest community run Python conference in existence. I’ve been attending since 2014, although I’ve missed the 2017 and 2019 editions. I gave keynotes in 2016 and in 2020 and I have served on the Code of Conduct committee multiple times (and again this year).

While EuroPython has been around for some time (in fact, it’s a little bit older than PyCon), the EuroPython Society in the past couple of years has seen an influx of new faces and new energy, and I’m really impressed with their commitment to experiment and improve.

I’m particularly happy to be involved since this year (and last year) EuroPython has partnered with me to hold a Trans*Code event, which will have just finished a few hours before this post goes live. I’ll be writing about Trans*Code at some later point, but for now it’s enough to note that it’s an informal hack day intended to give a welcoming and centering space for trans folk in technology.

Secondly, I’ll be introducing one of the keynote speakers, Sophie Wilson. Sophie was designer of (among other things) the first RISC CPU, which became the ARM line that powers the world’s smart phones and so many other devices.

I know from experience that the combination of trans-Atlantic jet lag and a major conference will probably leave me wiped out (have I mentioned that I’m not as young as I used to be?), so I’ll probably do what I can to have next week’s entry done in advance as well. If all goes according to plan I hope to use that entry to introduce a new feature here.

Ah, that's probably too dramatic. I suppose it was probably like a lot of meetings people endure at work or as organizers - meandering and indecisive, grinding and tedious, and using too much time for too little result.  But at the time it felt like a disaster to me. I think that was because I'd always hated suffering through meetings like that, so the feeling that I had inflicted another one on the world was hard to bear.

It started with EuroPython

It was during my first year on the board. One of the first things a new board does every year is elect officers. As someone new on the board I hadn't really expected to serve as an officer, but EuroPython changed my mind. 

EuroPython entered into it because of a combination of facts. First, in spite of not really conducting business at in person members' meetings, the PSF did in those days hold an official in person members' meeting at EuroPython. When it came time for the board to choose officers, it came out that holding such a meeting required either the board chair or a vice chair to preside. 

In fact at the time that was pretty much the main thing a vice chair was good for - presiding over a meeting if the chair wasn't present. I was in the process of transitioning back to living in Chicago from London, so I was one of two board members planning to attend EuroPython. The bylaws of the PSF allow for more than one vice chair, so it seemed like a good idea that both of us attending EuroPython be selected as vice chairs. 

The two of us did indeed co-preside over a PSF members' meeting at EuroPython that year, although to be honest, it needn't have been an official members' meeting. We talked a little about current projects and plans, we answered questions, and that was about it. It was more an informational talk than a members' meeting and I'm pretty sure anyone on the board could have handled it, but we had fulfilled our vice chair role. 

We had been elected in May, as I recall, and EuroPython was in July, and once it was finished, there was little need for even one vice chair. The board met every two weeks via phone call combined with a slack channel in those days, and months went by routinely with the chair present and in charge. 

Until one day it turned out that the chair couldn't make it to the meeting. We had two vice chairs, and I was new to the board while the other chair had experience, so presiding naturally fell to the senior vice chair. It seemed pretty set that I wouldn't have to worry about running a board meeting in the foreseeable future. 

My turn to chair a meeting

Or so I thought. It turned out that a month or two later BOTH the chair and the other vice chair would be unable to attend the regularly scheduled meeting. With meetings every two weeks there wasn't really much room to move meetings and at the time the board was much more involved in the day to day business of the organization, so the show had to go on. I was up. 

I wasn't particularly worried. Having been a teacher for some 25 years, and then a department head at work after that, being in front of a group of people, either in person or virtually, wasn't scary, so I just assumed everything would be fine.

Narrator: Of course everything wasn't fine. 

It was not a good sign that I was a bit halting and awkward as we went through the minutes of the last meeting and the other administrivia to start the meeting. Then as we meandered through the items on the agenda, things seemed to get worse. And worse. You've probably suffered through something similar to what my meeting became - awkward pauses, inconclusive and irrelevant discussion, no conclusions, things just drifting along, slowly, so slowly. 

In fact, I found myself sweating, all too aware that this meeting was becoming exactly the sort of lingering, indecisive waffling that I had always loathed in meetings led by others over the years. And this time, it was my responsibility, and I seemed to be unable to do anything about it. 

I nominate this as my perfect nightmare - give me falling helplessly, being hopelessly lost, being chased by a monster, or any other horror over being stuck in the limbo of an endless meeting of my own creation. 

Fortunately another board member came to the rescue or we probably would still be stuck in that meeting. They politely started making suggestions, "wouldn't X be a way to handle this situation?" "don't you think we should end discussion on this and vote?" "Shouldn't we move on to the next item?" and so on. It was humiliating to be led by the hand like that, but it was also my  salvation. 

That experience stung a bit, but that was a good thing. I started paying attention not just to the topics discussed in the meetings, but to how the meetings worked.

A second chance

When I was re-elected to the board the next year, I again offered to serve as a vice chair (and was duly selected), again so that we could have a members meeting at EuroPython. And again the resulting meeting was more informational than anything else, but I fulfilled the purpose of my vice chairmanship.

There was a significant change that year, though. Since the former chair did not want to continue as chair, the person who had saved me from twisting in the breeze in that disastrous meeting stepped forward to become the chair of the PSF board. And that’s when my education in running working meetings really began.

While I'd started paying attention at the end of the previous year, this year I really started studying what the chair did as they led our meetings. This chair was particularly efficient at running meetings, so I paid close attention to how they ran meetings and thought a lot about what they did and what preparation they must have done. I was determined not to inflict another awful meeting on my fellow board members if I ended up presiding.

That study soon was put to the test, since about halfway through that year the chair had conflicts that left them increasingly unable to attend meetings. The job of presiding over meetings increasingly fell to me as a now experienced board member, and by the end of the year I was presiding more often than not. 

That gave me the chance to practice what I'd been studying, and to combine it with what I'd learned teaching and leading teams. As I finished that year on the board, I wouldn't claim that my meeting management was perfect, but I never again had to suffer through the slow hell of a meeting where I'd lost control. 

In fact, as the board's term ended the chair encouraged me to run for the board again and to serve as the board chair for the following year. As they said, for the past few months, I'd been filling the role of board chair anyway. I had been thinking that I wouldn't run for the board again, but she and a couple of other board members changed my mind. This was the year where we switched from board members having one year terms, and I was lucky enough to be elected to a 3 year term. That was the start of my time as chair of the PSF. 

Guidelines for presiding over a working meeting

That unfortunate first time experience chairing a PSF meeting had taught me some guidelines for presiding over meetings that I have followed ever since. In the hope that you never find yourself leading a horrible, awful, not very good meeting, here they are:

• Know why there is a meeting. Why is this group of busy people being asked to drop everything to attend this gathering? And no, answers like, "it's Tuesday" or "we haven't had a meeting for a while" aren't good enough. Could this meeting be replaced by an email? If so, then send the !@#$'ing email and give everyone their time back. If there are things to be discussed, decisions to be made, votes to be taken, then do it. Just be clear about it, and have those items on the agenda. 

• Prepare. Someone has to set the agenda, and if that's you that's the first job. After that, read any related documents, message threads, emails, etc. so that you are ready to both participate and guide the discussion. It may even be helpful to have some preliminary chats with others involved, so that you have a game plan to handle particular items.

• Plan what you want to happen. No, that doesn't necessarily mean deciding the exact outcomes in advance, but you can visualize the state of affairs you want after the meeting: a decision made on question A, someone assigned to work on item B, a timetable for discussing complex item C, and so on. If you don't have an idea of what should happen during the meeting, I promise you it won't happen, and you're likely to drift around helplessly.

• Decide what is most important and urgent. Don't leave truly important and urgent items to the end. If you do, you will inevitably use up your time talking about less important and less urgent topics, and run out of time for the important stuff.

• Match the agenda to the meeting time. If you have 3 hours worth of topics to discuss, trying to cover them all in 45 minutes will be doomed to failure. You either need more meetings or (more likely) fewer topics. 

• Manage the time spent on each topic. Use the allotted time well - many times discussing something for twice the time will not make the decision twice as good. Discuss an item as long as necessary, but no longer. While no one wants to cut people off rudely, it's your job to move things along, so don't feel shy about setting a time limit for a topic and sticking to it. If something absolutely requires a lot more discussion than the time allows, either schedule another meeting or get agreement to remove other items from the agenda.

There are lots of ways to follow each one of these points, of course, and some of them may take more practice than others, but even if they're not followed perfectly, these principles will make your meetings better. I promise.  

Have a favorite meeting horror story? A pet peeve you want to get off your chest? Other comments or ideas? Either email me at naomi <AT> naomiceder<DOT>tech or leave a comment.

My last story told the positive side of the Fort Wayne LUG. We had a run of some 8 years with the same basic group of people, we became friends, and we shared some good times. Clearly we did some things right, and it was great to have a chance to reminisce a bit about that. 

On the other hand, as I look back there were some things that we didn't think of or didn't handle so well. This week I want to talk about some of those things. In the past 20 years since we started our LUG the world and the way we view it has changed a lot, but I have to admit that even by the standards of the time there were some things we missed as a community.

So what did we miss? Probably everyone involved would have their own opinions, but I can think of three things we could have done better. This is not meant to take anything away from what we did accomplish, and to be fair all three of them continue to be challenges for many self-organized communities. 

Diversity

First of all, we didn't think very much about the kinds of people we were attracting, nor did we consider doing anything to bring in different types of people. If you looked around at any of our meetings you would have seen mostly straight, cisgender (apparently ;-) ), white males. Yes, we had one Latino and one Black regular, and a few women attended semi-regularly, but in general we suffered from the same lack of diversity as most open source groups of the time.

It didn't help that we were in Fort Wayne, where there was relatively little mixing of races. Also not helping was the ethos of Open Source groups generally at the time. Our LUG started in the era when open source communities were seen largely through a Libertarian "meritocratic" lens - it was up to the people concerned to show up, and doing anything that would have catered for particular groups would have seemed almost against that ethos. 

But in fact, being in a limited market we as were should have made us more willing to recruit from other groups. Since we apparently had most of the middle aged white guys who were interested in Linux, clearly we should have started thinking about how to attract women, people of color, and anyone else who wasn't already at the table.

Of course one thing that operated against that was that thanks to unconscious bias we assumed that there were no Linux geeks (current or potential) in those other groups. Because if there were, they would have somehow found us and joined us, right?

Code of Conduct

Not only did we not consider trying to attract people who were different from us, even if we had I think that effort would have had problems. The reason I say that is that we also had given no thought as to what our standards for behavior were, nor to how to make sure those standards would be honored. 

If you would have asked us at the time, I think we would have all argued that we didn't need a formal code of conduct - we were all adults who knew how to behave, we were good people, and we didn't need anything formal for us to treat each other well. 

Well almost all of us at any rate. We did have one regular who I would say made most of the rest of us uncomfortable. Let's call him X. He was older, quite obese, and seemed to have questionable hygiene at best. He would repeatedly ask beginner level questions that were almost incomprehensible, and when someone tried to answer and talk him through how to fix the problem, he struggled to follow the answer and inevitably turned up later with that problem unsolved and yet another puzzling question about some basic feature. 

But that wasn't what made everyone uncomfortable. Sure, it was a bit frustrating to try to help someone who seemed incapable of understanding even the simplest advice, but as far as I could tell no one was bothered much by that. 

What did make X truly creepy was when he started talking about his political and sexual beliefs. First of all, we mostly avoided topics like politics and religion, having a sense that they were not our primary interest and would only cause trouble. So it was when X would start alluding to his interest, or support, or whatever it was, for voluntary castration, and his opinions about relationships, that things got weird. I’m not sure we ever got the full version of whatever it was, but we heard enough to know that we weren’t interested in hearing more.

While the rest of us felt that this was clearly inappropriate, we weren't very forceful about stopping him. I think we felt that we didn't really have the right to shut anyone up, let alone ask them to leave. As I've mentioned, this was at a time when the open source world tended toward Libertarianism, and since we were all adults, it felt like there wasn't much we could do beyond ignoring X and changing the subject. And of course, ignoring him and changing the subject was only sometimes successful.

It was probably just as well that we didn't have many women regulars when X was around, because I'm pretty certain that his vibe would have driven them away in short order. 

In retrospect our dealing with X serves as a great example of what  a Code of Conduct is good for, particularly when it's a reasonably well developed one. For example, something like the Python Software Foundations general CoC would have been enough for us to shut X's creepy rants down or ask him to leave. 

That was the first time I really started to grasp the value of having clear standards of behavior and ways to enforce them. Again, back in those days, I think many (white, straight, cisgender, male) people in Open Source tended to think of such standards as just a way to take away the freedom of the main group in the name of protecting the delicate feelings of some minority. But in fact those standards are something that can make the experience better for everyone.  

Succession

The Fort Wayne LUG still has a web site with this summary of its history:

Fort Wayne LUG 1.0

Our group was founded in 2003 by Dr. Ceder of Canterbury High School, a published expert on Python, along with Rob Ludwick, and later Simón Ruíz. We met bi-monthly at one social and one learning-focused event. After many years of well-attended and productive meetings, various members began transitioning to new chapters in their lives and attendance began to decline in 2012. In 2013, LUG transitioned to a social meetup only.

Fort Wayne LUG 2.0

In 2014, with the gracious support of Sweetwater Sound, we began meeting bi-monthly again, with social meetings at the Mad Anthony Brewing Company on Taylor street, and learning events held at Sweetwater-supplied facilities where we welcomed new members and saw old friends once again. In 2017, again due to life changes and a scarcity of monthly presenters, we again transitioned back to a social-focused monthly meet-up.

Fort Wayne LUG 3.0

Beginning in the autumn of 2017, we have decided to transition to a monthly/quarterly format, where we will continue to have social meetings once a month, with regularly-scheduled quarterly learning events with a pre-announced speaker. We are also planning other occasional special events when member schedules permit.

(Note: my comments are based solely on the first iteration of the LUG, since I wasn’t present for the other two iterations.)

I would say that all three iterations described above mention symptoms of the same problems, and that they are rather similar to the issue that we faced as kids in CCAOS. I think the issue was that there was no inflow of new members and there was no way to handle succession when key people inevitably moved on. 

Both of these issues still plague open source groups today, although these days more people are aware of them. The most common concern these days is losing leaders or key players to burnout, but I've also seen key people leave because of changes in employment, moves, and other changes in their lives. 

Three things we should have done

And it's important to be aware that the problem is not only that people will leave, it's that we often don't have anyone to take over for them. In retrospect that is one lesson from my time with the Fort Wayne LUG - that to truly thrive in the long term a community needs to do at least 3 things. 

Keeping leaders engaged

First, a community should do what it can to keep its leaders engaged. This doesn't mean just avoiding burnout while they languish in the same role, but having other possibilities or other roles so that leaders can grow and be refreshed. It's true in the LUG's case, both Rob and I left because we found jobs in other cities, but there are many cases where burnout is the cause of a loss of leadership.

New members

Second, a community needs to have a steady stream of new people. In the LUG's case, one problem was being in a small market, something that we couldn't change. But another aspect of it was the fact that we didn't do as much as we might have to attract a wider range of new members. 

Sharing leadership roles

Finally, even with plenty of members and taking good care of the leaders, a community will probably ultimately fail if it doesn't have a culture that encourages new leaders to step forward. If there is one message that I have found vital for communities over the years, this would be it. It's terrible to have a leader burn out, it's disappointing to have a leader move away or otherwise move on, but it's probably even worse to have a leader (or a community structure) who clings to their position, and is reluctant or refuses to let new leaders take responsibility.

I think it's important to consider that in taking the responsibility for keeping the LUG going, Rob and I weren't on some power trip - we really thought we were doing a good thing by making sure the group kept functioning. And it really did seem like no one else wanted the job. This was, I suppose, another case where good intentions alone were not enough. 

So to my mind that's where we went wrong with our LUG. As welcoming as we were, we didn't take enough positive steps to attract new and different people and we didn't really have a culture of encouraging the sharing of leadership.

For me, at least, this doesn't take anything away from what we did right. We had a friendly, happy, and productive community for several years, and it undoubtedly was a positive experience for many of us. "And yet," I hear myself asking in the back of my mind, "wouldn't it have been grand if that group had continued to thrive right on down to this day, even after several of us moved on?"

Again, if any of this touches a nerve or inspires questions, comments or ideas, please feel free to get in touch, either by a comment here or pinging me at naomi <AT> naomiceder.tech.

Last week's post about starting a LUG mostly got reactions from people who were a part of it, or would have liked to have been a part of it. One friend who wasn't a part of that club did confirm the social awkwardness of tech focused clubs, particularly towards new people. I think it will be worth thinking about what makes groups more or less open and welcoming. What are the things that they do or don't do? 

Settling in

This is now the fifth week I've written here, and I would say I'm starting to settle in. I spent a few weeks before launching getting the first stories roughed out, deciding on the platform, setting things up, so I suppose I'm not almost 3 months into this project. I'm feeling more comfortable and less pressure, although to be fair, there is some lingering impostor syndrome. As a trans person I've had a lifetime to get used to dealing with it and it's usually pretty manageable, I think. 

Questions and comments

To turn the focus outwards, I would be interested in hearing if you have any comments, or questions, or whatever. If there's something about communities you would like to compare notes on, or ask my opinion on, or just talk about, leave a comment here or send me an email at naomi <AT> naomiceder.tech. I'd even be open the possibility of having a guest post or two, so let me know. 

Subscribe now

That's about it. This is an "off" week, but next week I'll be back with some of the things we didn't do so right when we created our LUG.

The second tech community I helped create was a Linux users group. More than 30 years had passed since the end of CCAOS, and by that time I had ended up as the Latin teacher at a small mid western private school. Thanks to an interest in coding and a willingness to tinker I transitioned from Latin teacher to being the director of technology in the late 90’s. In those days that meant that I was the system administrator, computer repair tech, phone system expert, chief software developer and support staff for online learning and grading systems, and high school computer teacher.

The year 2000 passed without the dreaded meltdown so widely feared, but my seemingly never ending list of job responsibilities had left me pretty much burned out. Perhaps sensing that I was about to hit the wall physically and mentally the administration finally decided to hire someone to assume part of that load. 

The person we hired to be our support specialist was Nathan, a former student who I had been close to, and that gave me the relief I needed. It also meant that there were two minds sharing my office and coming up with new ideas. One of the first things my new specialist did was start talking me into using Linux servers. I had been experimenting with Linux for a few years, but the problem with a one person shop is that there is never enough time to test and actually deploy new solutions. 

With two people, that equation changed. We started deploying Linux servers, ultimately replacing our venerable Novell Netware, and we pushed each other as we experimented more and more with this new OS. The projects ranged from serious, as in moving our file server to Linux and setting up mail servers, to silly, like the time I programmed a cron job to use an X10 home automation relay to cycle the power to the coffee maker so that our coffee wouldn't taste scorched after a couple of hours. We compiled custom kernels to run Linux on our laptops, in those early days a process bordering on madness that could take days to complete. 

So it was not at all surprising when one day Nathan said, "You know, we should start a LUG (Linux Users Group)". And I responded, "Yeah, I was wondering about that. Let's see what we can do." Fort Wayne, Indiana in those days was hardly a tech hub, but a search showed that there was an informal meetup in town that met once a month for beers and to discuss Linux. The next meet-up we were there. 

Over beers the four or five of us present agreed that having a more formal group would be cool, but for a while things were stuck at the talk stage. To start a community, someone needs to provide an initial push and actually do something. That push came when a high school kid, the son of a professor at the local university, joined our meetups (accompanied by dad, of course, since we were still meeting in a bar).

Thanks to his insistence (I think we mostly thought of it as "pestering" at the time) we tried having meetings at the university, and giving presentations on various Linux topics. I remember talking about how cron worked and how to schedule cron jobs, things like that. 

Those meetings were fine, but not without issues - for access to the university we needed not only the high school kid, but also his dad. A few times they didn't show up, and a bunch of us were stuck in the parking lot. And there was another issue familiar from the experience with our astronomy club, but this time from the other side - a high school student, particularly an older one like ours, will graduate and probably leave town. And to be fair, it was pretty clear that the student and the few friends he'd recruited to join our meetings weren't entirely comfortable being stuck with a bunch of old timers like us - some of us were… over 40.

But the kid had done his job - we felt that we wanted to keep having meetings, but we needed a more practical venue. In our first research on running a LUG, Nathan and I read that having a reliable venue and a predictable schedule are key factors in establishing a group. You don't want anyone, either members or future members, guessing whether or not there's a meeting this week, what time it might start, or where it might be. All of those details should be so regular that even if someone doesn't get a meeting announcement, or doesn't read it, they can still turn up and have a good chance of catching a meeting. 

Regular meetings find a home

With that in mind, I offered our high school computer lab for regular meetings. I could have (probably should have) done it sooner, but I was feeling that same reluctance to step up that so many feel. Offering the space was easy - our school was small enough and I had enough authority that there was no problem in booking it. The only catch was that I had to be at every meeting, unless I drafted my support specialist to take my place.

But with the venue and schedule set, the Fort Wayne LUG started to establish itself - once a month we still met for beers and conversation and a local watering hole1, and then two weeks after we met for a meeting with presentations in the high school computer lab. While some folks preferred to attend one kind of meeting over the other, those of us in the core group almost always attended both. 

Over the years we did the usual LUG stuff - we all gave a ton of talks, we had guest speakers, we held installfests, holiday parties, barbecues, and so on. Our interests ranged from the serious to the playful. At least one meeting (and some extra Saturday sessions) was devoted to writing and testing the Python code to coordinate the aiming and firing of a battery of USB powered nerf missile launchers. It sounds silly (and it truly was) but since the launchers had to be attached to half a dozen different computers with just one control station, and we had to take into account the stations' different positions, it was also a fairly sophisticated technical problem, combining geometry, servers and clients on a network, flexible ways to manage configuration changes, and more, a real geek's delight. 

What did we do right?

As we continued with two meetings for years, the core members became quite close. As I look back it was an amazing run. What had we done right to keep things going like that? What was it the LUG offered its members?

I'm not sure I know all of the answers to that, but I can think of a few possibilities. First of all, it would be fair to point out that Fort Wayne was not the world's largest tech market. If you were interested in Linux adjacent topics, the Fort Wayne LUG was pretty much your only option. 

Second, in those early days of Linux new users had more problems and fewer resources. The countless YouTube videos and other resources had not yet arrived, so if you wanted help with troubleshooting your installation (and in those days there were plenty of troubles to shoot) one of your best bets was a LUG. And we did a lot of trouble shooting at meetings. Folks would haul in their entire desktop computer setup so that club members could help figure out a problem. 

But maybe the most important thing that the LUG offered was social connection. We started as a social group, and we kept on being a social group. The excuse to go out and socialize with other geeky folk was something rather rare, I think, and being at ease with meeting people is not always our strong suit. I've attended LUG meetings in other places where the level of social awkwardness is about on the level of the start of a junior high dance. But our group had already broken the ice - more than ½ of the members at any meeting had been out for drinks and a meal two weeks before, so as a group we had a much more open and friendly vibe. The fact that the regular members felt comfortable with each other meant that newcomers could be made more comfortable as well. This was our superpower, I think - the atmosphere of the social meetups, where we would always invite newcomers to pull up a chair and join in, carried over to the regular meetings. 

So I think that combination was our strength: we offered a rare Linux-y, techy oasis in a relatively small town, we were generous with troubleshooting help, and we had a built-in mechanism to encourage social bonding. We didn't actively think about any of those things at the time, of course, and we probably wouldn't have realized at all how important the social aspect was. But of all tech groups I've been a part of over the years, the Fort Wayne LUG was one of the most welcoming. 

This post tells the story of some things we did right, however inadvertently. Of course there were a few things that we didn’t do so well and I’ll talk about those in the next story.

Many thanks to those who read and reacted to my first story. I seem to be picking up subscribers slowly, but steadily. To be honest, getting subscribers at all is a bit of a surprise, but it’s nice to see, even if it does add a bit to my sense of urgency. Which brings me to my first point this week…

As I work on writing these pieces I am coming to realize that a full piece a week is too ambitious a pace. Yes, it is true that I'm no longer working a regular job, what you might call "retired", but I don't want to be writing all the time. For one thing, getting away from a daily grind is one of the reasons I retired, and for another, I have stuff to do, dammit. 

So my current plan, totally open to modification going forward, is that I'll move to producing a new story every 2 weeks, and on the off weeks, I'll share some easier bits and pieces - reactions to previous stories, reflections, and administrivia (like this).

Reactions

Fortunately for me this week, my story about my first community got some interesting reactions. Many of those came from old friends who were a part of CCAOS and had shared those experiences. Some others came from people who had experiences that contrasted with ours. 

One of the original kids in the club went on to a career in experimental science, and his reaction was that "flying by the seats of our pants (both organizationally and financially)" had been key in equipping him to handle the many challenges of perpetually underfunded research projects, both in terms of constructing apparatus and in dealing with shaky organization. 

I hadn't considered that, but it rings true to me. I have also made my way professionally by being able to handle "a high degree of ambiguity" as one boss put it, and by being able to pull various resources together to solve problems. No doubt that that early experience and its eventual success played a big part in preparing all of us for our future challenges. 

Another old friend recalled how the club had had a feeling of community and home, where geeky  interests were welcomed, not bullied. To me that's the best testimony to what that tiny community meant to me, and what is essential when I think of a true "community". 

Another friend, who was not part of our CCAOS community, told of the opposite experience in her youth, of moving from a church community where she felt some connection, to a different church where there was no one her age and feeling isolated. I find that perspective particularly intriguing. If we as kids had a positive community and have felt its positive influences in the decades since, what sort of challenges do people face if their early experiences with community are not affirming? Or if what one recalls includes a sense of loss?

It seems to me that a consideration of negative experiences of community and their ramifications would be worth discussing in one of these stories, so if anyone would like to share anything about that, either leave me a comment or send me an email at naomi DOT ceder AT gmail DOT com. 

As always, feel free to subscribe if you want to get this in an email:

Subscribe now

And if you feel inclined to share this, well, that would be lovely:

Share

And with that, I'll get back to work on my next story. Cheers.

In central Nebraska the summer days would fade slowly, and if there no were storms the sun would take its time merging with the hot and dusty horizon. In the lingering orange twilight you could hear the irrigation pumps in the corn fields nearby, and you could catch a whiff of a freshly mown lawn. As it got darker the bugs would start coming out, mosquitoes of course, but also June bugs buzzing, crickets singing, and fireflies flickering. 

Around the lights there would be moths, but we avoided the lights, moving to the darkest corner of the church parking lot as the sky darkened. Lights were the enemy because at barely 11 years old we were setting up our little telescopes for a night of astronomy. 

Our target might be the moon, an easy target for beginners, or maybe Jupiter, bright and easy to find, with its four largest moons visible to even our puny telescopes, just as they had been to Galileo. Through the better scopes we could see the rings of Saturn and convince ourselves that Mars was indeed red, even though we couldn't make out the “canals” we read so much about in sci-fi stories. As we grew more skilled, we moved on to pursuing the star clusters and hunting the nebulae cataloged by Monsieur Messier centuries before. 

Those are my first memories of my first "community" that was based on a shared interest. We didn't think of it as a "community" then, not in the way I think about communities now. Back then, it was just a club, a bunch of geeky pre-adolescent boys and girls who met with the Methodist minister in the name of astronomy and telescopes and stuff. 

Stars in a summer night

The evening meeting would start in Tap's (as he was known to us, his wife, his parishioners, and the world) office, where we'd discuss whatever space or astronomy news we had and trade opinions on science fiction stories and TV shows (of course, we all watched Star Trek). Occasionally Tap would read us a sci-fi story from the latest (discreetly covered) issue of Playboy. 

Particularly in the summer, those meetings were usually just a way to pass the time until it got dark enough to go outside and set up our little telescopes in the church parking lot to observe the heavens. 

With Tap as a gentle, but unflappable, presence to guide us, we grew, both as a club and into our adolescence. At Tap's suggestion, we soon dubbed ourselves C.C.A.O.S. for the Central City Astronomical Observers Society. It was pronounced "chaos" which delighted all of us and puzzled everyone else. 

We recruited guest speakers, we went on trips to see an actual moon rock and to hear Pete Conrad, the third person to walk on the moon. Tap also booked us a booth at our county fair and with only a little bit of help we decorated and manned it for the duration. We even constructed a mini planetarium and we took turns giving tours of the heavens as projected onto a sky of taped together newsprint. With the donations we raised from that, we bought a mirror grinding kit and committed to grinding the mirror for our own 12 ½" telescope. It was all pretty amazing for a bunch of kids in the middle of the Nebraska plains. 

Losing a leader

Being kids, it never occurred to us that something might happen to change everything. At least it never occurred to us until Tap was reassigned to a different parish an hour's drive away. Tap had convinced the incoming Methodist minister to take over CCAOS, but it was a poor fit. After all, an interest in astronomy was hardly a requirement for being a Methodist minister, and in spite of his good will, we could tell that the new guy didn't really share our passion for astronomy at all. Enthusiasm waned, the telescope project stalled, and meeting attendance got thinner. 

Tap had always kept to the background and encouraged us to do things on our own, so we had taken him a bit for granted. Now we were feeling his absence. We knew that we needed to do something, but what? How do you move on from the loss of a key leader? 

It wouldn't have been surprising if we'd just given up, if we'd each moved on to other activities. You wouldn't really expect much more of some barely teenage kids. In fact, the same thing often happens with adults - when a key leader moves on, no one wants to step into that role. They have too much to do, they feel they don’t know how to take over, they’re waiting for others to come forward, whatever. So people drift away, and many times the group withers away. 

Yet for some reason we didn't give up. As we talked about it, we came to realize that we needed to find a sponsor interested in what we were doing. To our minds, "firing" the Methodist minister meant that we also probably had to find a new place to meet. So we had two problems to solve. 

Finding a leader

We finally decided to approach Jim, our middle school science teacher (by this time we were in our first year of high school. He had taught us eighth and ninth grade physics and earth science, and we had gotten along well with him. A small delegation of us went to his classroom one afternoon and begged him to take over as our sponsor. 

Surprisingly, Jim agreed. We packed up our telescope mirror making stuff rather quickly and set up shop in Jim's basement. Unsurprisingly, the minister was just fine with being fired, so we parted ways with no hard feelings.

The next three years we spent much of our free time in Jim's basement, walking around the mirror grinding stand (an oil drum full of water), taking turns grinding our giant mirror. We also resumed our trips, had observing sessions in the backyard or drove out into the country to set up telescopes literally in corn fields, in both sub-zero winters and Nebraska's hot and humid summers. 

As a club or community we had little hierarchy, no formal dues, and I don't recall a sense of people being shut out. Pretty much everyone got plenty of turns pushing the 20 pound 12" glass disk over the grinding tool, a disk of the same size. At the end of the process, the expert work of ensuring that the curve was "figured" to be optically correct fell to the one club member who'd done it before. (He also did the figuring on the 6" reflector I built at the time, which I still have to this day.) 

We struggled together, led by Jim's experience and knowledge, to solve all of the problems of building a complete telescope and an observatory to house it. Looking back, it should have all been impossible. We were just a bunch of high school kids, with a very limited budget. But somehow an old car axle (the product of a daring daylight raid on a junker in a cow pasture) became a motorized telescope mount; an irrigation pipe became a telescope tube; the fiberglass resin our music teacher used for his hobby of modding Corvettes became a spring loaded mirror mount; and the corner of a corn field sprouted a modest concrete block observatory. And as far as our skills allowed everyone was involved in that work. 

End of the journey

Early in our senior year of school we were enormously proud when we dedicated our observatory, dubbing it the Taplin-Weir observatory, in honor of our two mentors, who were both at the ceremony. Through the rest of that year we experimented with the telescope and astrophotography, finding various bugs in the telescope and observatory and working on fixes. 

In the years after we graduated we slowly drifted away, off to colleges and careers. There were no new members, so as we came home from college less frequently, the telescope saw less and less use. A couple of years after its completion the telescope suffered some misadventures, surviving a fire that wiped out a city block in our little town, then eventually being repaired and re-installed, thanks to the insurance. 

Eventually everyone moved on and with no users (it's safe to say that no one else in that little Nebraska town showed the same interest in astronomy that we did) the telescope and observatory we had built fell into disuse. 

Under-appreciated gifts

While we had no idea at the time, in spirit CCAOS was not so different from some of the tech communities I'm a part of today. We were only kids, true, but what brought us together was an excitement about the latest technology, which at that time was astronomy and the exploration of the moon. 

Through our teen-age years, CCAOS became a source of friendship, sometimes even early romance, and of connections many of us have maintained over almost 50 years. For many of us Jim and his wife Connie (who was our Spanish teacher) became our role models, our advisors, and our friends.

More importantly, our experience in CCAOS showed us what could be achieved by a group of people working together (even a group of kids in the middle of Nebraska) for a sustained period of time. In my case, and I'm pretty for others as well, the notion that surprising things were possible if you tried was a gift I carried into my later life. It gave me the confidence to attempt big projects and keep working on them until they came about. 

Our experience back then also illustrated some truths that I didn't understand at the time, but I've come to appreciate with experience. We saw that having a single leader can mean crisis when that leader has to move on. In our case, our answer was to just replace our single leader with another leader, but at least we had the sense to understand that without that leader we would be doomed. (Spoiler: the theme of leadership succession will feature prominently in the next few stories as well.)

We also saw what ultimately happens to a group when there isn't a steady flow of new members. The original members will eventually drift away, and when that happens, everything ends. 

Given that many communities of adults are still learning these very lessons, I'm not inclined to be too harsh with our teenage selves for failing to deal with those two truths. In fact, it took me a few more experiences and a few decades to assimilate those lessons, which is something I'll talk about in a later installment. 

On the other hand, even though our little observing society eventually collapsed as life happened, it also showed us that communities don't have to last forever to have value. In those days before the Internet just living in a tiny town on the Nebraska prairie was isolating, particularly for kids with interests like ours, so to have a group of like-minded folks to share interests with was a lifeline. 

In the years we were together we formed lasting connections, learned how to be a community, and gained a sense of confidence. Even if it didn't continue after we left, CCAOS served us better than we imagined. That's probably the last lesson our little community taught us, even though we were too young to understand - a community doesn't have to grow or last forever or be perfect to be of value. As long as it brings people together and helps them grow, even a little, a community has done its job.

Subscribe now

The power of stories

Over the past 40 years or so, I've done a lot of teaching, some writing, and a lot of speaking and community organizing. I've learned a lot from the experience (and have the scars to prove it), but one of the most important lessons for me is that stories are powerful. We humans use stories to make sense of our world, to understand how we fit in with those around us, and to deal with both the good and the bad we face in our lives. 

Thirty five years ago as a Latin teacher I could drill my high school students on grammar all day, but what they would remember after they left the classroom were things like a story of the fall of Troy, complete with chalkboard drawings (yeah, I'm that old) where the island of Tenedos looked rather like a flabby whale. I've given a bunch of talks that spelled out the issues facing marginalized people in tech in gory detail with bullet point slides, but what audiences remembered more was me telling my story of facing some of those challenges as a trans woman. 

And so it goes - stories carry information, feeling, and meaning in ways that other forms can not. With the right story, almost anything is within reach. Without the story, nothing seems possible.

I want to share some of those stores

My goal here is to distill and share some of the stories I've gained in the process of belonging to, creating, and caring for communities over the years. I'm most interested in the communities that arise around open source software, the Python language and its ecosystem, but I think these stories apply to communities in general. 

The stories I'll be sharing will be ones I've lived, or witnessed unfolding, or have heard from community members. They will not be made up fables, but they may be anonymized and occasionally the characters and situations may be composites, both to help keep things anonymous and to make the points clearer.  While the situations themselves may not always be flattering, these stories will always be told from a place of love and respect for our communities and the people who create them.

Join me

If you are like me in being interested in what makes tech communities tick, in how we can create them and make them better places, I invite you to join me for a few good yarns about people coming together. If you’re interested, here’s the subscribe button for your convenience:

Subscribe now

My plan is to share a story a week, but that will depend on a few things - the feedback I get, my recollection of times gone by, and how quickly I write things down.

What will it cost?

I’m not doing this for the money, so I can promise you that I won’t be pushing you for a subscription. Fairly soon, I’ll probably turn on donations, so that people who feel inclined can contribute, and I’ll certainly share that when it happens. Otherwise, the content here will be free to read, but for the moment under my copyright (CC licensing is something else that I’ll consider soon).