Sumana

As I celebrate my fifteenth wedding anniversary and think about the long durable things we work on, I am thinking about patience.

"Somebody Will". "I am willing to sacrifice something I don't have / For something I won't have / but somebody will someday."

I've been attempting to work on my patience. I'm working on a book which will be the longest document I've ever written, and which will probably go through more and longer editing and revision passes than anything I've ever made. I'm doing this because I see an infrastructural need in free and open source software, and even if this book succeeds it will take years to change the field. The project of FLOSS, itself, trying to liberate people from being programmed by the software we use, is so huge and slow. And that's only one of the wheels against which I want to put my shoulder; there are so many gross, exploitative, destructive systems I want to smite.

I'm sustained by words by Tressie McMillan Cottom:

"You just have to know that they won your lifetime. It doesn’t mean you don’t try or work or whatever but you have to learn to fight for wins you won’t experience. That’s life, I think. That’s what I get from old Black people. You do it because it needs to be done, not because it’s being done for you."

and by João Costa Vargas:

“Once we accept that we are not wanted. Once we accept that we are not loved. It is very liberating. .... once we accept the logic of the runaway slave.... we can begin to do the work of abolition.”

I am loved; the support of loving friends -- like my spouse -- makes it more possible to accept the possibility, the reality, that I/we have opponents and that they do not love me/us. And to plant seeds that I hope the next generation can harvest.

Pulled up this screen to share a few issues I just filed with a colleague, and noticed one dimension of the contributions I've made to Python packaging over the past few years: https://github.com/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+org%3Apypa+archived%3Afalse+author%3Abrainwane (I think you can only see this when logged in, and possibly not everyone can see it).

48 open issues in the PyPA org, 91 closed.

On May 3rd, 2019, two friends and I are hosting "The Art of Python", a miniature arts festival at PyCon North America 2019 (Cleveland, Ohio), focusing on narrative, performance, and visual art. We intend to encourage and showcase novel art that helps us share our emotionally charged experiences of programming, particularly in Python. We hope that by attending, our audience will discover new aspects of empathy and rapport, and find a different kind of delight and perspective than might otherwise be expected at a large conference.

There's more about this at my co-organizer Erty Seidohl's blog post, including an invitation to also propose your "not-talks" to !!Con.

In short, we are interested in how fictional narrative, visual and performance art, and different presentation formats can make different kinds of teaching and representation possible.

"The Art of Python" is seeking your proposals now and the deadline for submissions is 28 February. And if you've never written a play and want guidance so you can write your first, we'll have a guide up on 1 February to help you!

Thanks to Erty and to Brendan Adkins for co-organizing "The Art of Python" with me! Thanks to PyCon's Hatchery program for new PyCon events, which makes this festival possible! Thanks to Jackie Kazil for the festival name! (My codename was "Spectacle!" which is probably misleading and less accessible.)

I am trying out a bunch of thoughts on what some different approaches to software are... beyond waterfall/agile, free software/open source, and FLOSS/proprietary, and beyond shrinkwrap/internal/embedded/games/throwaway....

* Deliberately ephemeral
* Accidentally ephemeral (like some Minecraft mods or personal one-off scripts)
* Enterprisey, scale-centric
* Artisanal/personal/couture
* Educational (as in, writing source code specifically to be read as an aid to learning, as in a presentation, test, blog post, or textbook)
* Angry, competitive, insulting
* Cheery, collaborative, complimenting
* Innovative
* Stable
* Mimetic (copying functionality/approach of other existing software)
* Particularly amenable to any one of the Felder-Silverman engineering learning styles (and not to its opposite)
* Social norms (especially around permission, redistribution, reuse) taking the place of copyright when in a copyright grey area
* Voluntary
* Paid
* School project
* Taking donations, but passing some of them to upstream
* Gift culture
* For-profit proprietary
* For-profit open source
* Copyleft licensing + charging extortionate fees to license differently
* Corporate non-profit open source
* Free software
* Specifically playful, alternative, queer free software
* Copyright abolitionist or nearly so
* No license out of neglect/convenience (the "GitHub License", sort of formalized as WTFPL)
* Piracy, open and proud
* Piracy, furtive and/or (interally seen as) hypocritical
* Grey market (like Minecraft mods)
* Despotism by founder
* Willingness to hand maintainership over
* Benign neglect by owner/maintainer of core infrastructure
* Monolithic
* All the different ways "not monolithic" can look (plugins, APIs, scriptability, portability, content/logic/presentation...)

I'm brain-dumping this as I think noodly rambly thoughts about open source software communities and abstractions we might borrow from other software communities. I absorbed some assumptions fifteen to thirty years ago, of how to use and make software, how open source citizens should act in open source communities, about what the rules are, and about the sets of expectations we have about how we talk and work with each other. And I'm wondering what a genuinely different approach would look like.