Thursday, August 10, 2017

The Ethical Maintainer: Community Service Award Recipient Glyph Lefkowitz


Glyph Lefkowitz was barely 20 years old when he promised himself, "I am never going to use a proprietary programming language again!" He had been writing a Java application for his first professional programming job, which he had started directly after high school. The firm was a mom and pop shop that sold inventory software. Glyph was hired to rewrite their application for a contemporary platform: Java's Abstract Window Toolkit. With the hubris of the young, he promised, "Sure, I can rewrite your whole application in a new language." He could do it working only four days a week, too, and make time to work on his multiplayer online game.

"I had a pretty terrible experience with Java," he says. In those early days of the Java AWT, on classic Mac OS it leaked a tiny bit of memory every time it opened and closed a window, and in his application, nearly every task a user desired required opening and closing a window. On the constrained Macs of the time, the application would crash after about 100 tasks, often taking the whole OS down with it. The AWT was proprietary, so there was no way to fix the bug himself. "I was fired," says Glyph, "because I was having a nervous breakdown over this."

The Birth of Twisted

Meanwhile, Glyph was also building his multi-user text adventure in Java. He wanted to rapidly experiment with varied gameplay logic, and to avoid constantly restarting the server as he tried new code, he built a system in Java that could load new modules at runtime. When, burned by his Java defeat, he switched to Python, he found that practically all of the Java code required to load modules and execute them simply disappeared.

The switch from Java to Python had another effect, which profoundly determined the direction of Glyph's career. He discovered async.

Glyph's friend James Knight, who would become an original contributor to Twisted, helped with the Python port. The initial code for the Python server ran a thread per player, but Knight used a select call to determine, within each thread, whether it was time to read a message from the player or send one. When young Glyph saw that code he was astonished. "It's doing two things at once! But it's also kind of one thing." After all the bugs he'd battled in his multithreaded Java, he thought, "Couldn't we just do one thing all the time?" He and Knight rewrote the entire game server as a single-threaded event loop. He liked how it simplified the code. Only one thread accessed a shared data structure at a time. His original motivation to use an event loop was not efficiency: rather, it was how much easier it was to make his code correct.

Glyph says that his strength, in his 20s, was knowing what he didn't know. His father is a programmer, and he taught Glyph that most programming techniques are already well-known. Therefore when Glyph and James Knight got their event loop working, Glyph thought, "Someone must have done this before." He searched on Alta Vista and found the ACE project, which included a C++ event loop. Glyph refined his Python event loop based on the best practices he found in ACE, and this became the basis for Twisted, which is now one of the oldest and most influential of all Python libraries.

Based on this early experience discovering that event loops were a well-known technique, Twisted's motto is "no new ideas allowed." Twenty years later, however, Glyph has begun to innovate on the margins. For example, his Tubes library implements asynchronous I/O as "flows" of data with flow control and backpressure. But when it comes to event loops, he says, "There's so much prior art that coming up with new inventions is not worthwhile."

Twisted's Influence On Python

In the second quarter of 2017, the Python Software Foundation recognized Glyph Lefkowitz with a Community Service Award for his work on Twisted and his contributions to the Python community. Nick Coghlan nominated him, saying that Twisted "predates almost all other Python event handling systems by years, and still has by far the most comprehensive set of network protocol handlers." The decade-long journey from PEP 342's generators-as-coroutines, which enabled Twisted's inlineCallbacks feature and Tornado's Futures, to native coroutine support with "async" and "await", began with Twisted. Coghlan says that evolution could be reasonably described as taking the concepts first embodied in Twisted and drawing them ever closer to the center of the language.

In 2012, Guido van Rossum began writing asyncio, an async framework for the Python standard library. He collaborated closely with Glyph, as well as Tornado's maintainer Ben Darnell, to incorporate their best ideas in asyncio. He was interested in Twisted's notion of a Deferred, but he couldn't seem to understand it. Glyph says that trying to explain Deferred to Guido "was the worst time I've ever had on a mailing list." Guido wrote, "I really don't get Deferreds. Don't bother pointing me to docs or tutorials; I tried and failed." He said that Glyph's "snarky tone is seriously affecting my ability to process your response." Then he went silent for a week.

Glyph was devastated. He felt like he'd been flamed and ghosted by the founder of the language itself. Then Guido suddenly returned to the mailing list, with what Glyph calls "the most trenchant and keenly observed critique of the Deferred module. It was possibly the best code review I've ever received." It was suddenly clear that Twisted's Deferred would interoperate just fine with the new asyncio event loop. "We were all on board."

Responsibilities of Open Source Programmers

Glyph is distinct among Python programmers for his outspoken views on ethics. In his 2015 PyCon talk he proposed that programmers write a code of ethics, similar to other professions such as medicine and journalism. If we don't, he says, "someone else is going to do it for us, and they are not going to understand our field well enough to do it correctly." Since software is eating the world and it influences nearly all economic activity, we have a grave obligation to write code ethically.

Open source programmers often think we owe our users nothing, because we give away code for free. But this attitude ignores the benefits that we've gained. "Being an open source maintainer has opened all sorts of doors for me," says Glyph. "Whenever anyone does anything with Twisted the credit accrues to me. That's not really accurate, because there are lots of other maintainers like Amber Brown, David Reid, Ashwini Oruganti, Jean-Paul Calderone, Moshe Zadka, and Christopher Armstrong." Regardless, anyone who releases open source code engages in a subtle exchange with users, which obliges the coder to uphold some responsibilities. In my conversation with him, Glyph identified three responsibilities for open source programmers: to make clear promises, to secure our code, and to release code of appropriate quality.

Open source maintainers are uniquely obliged to make clear promises. If a maintainer abandons a project, her main obligation is to announce her departure and to transfer control. "Being an open-source maintainer is not a life sentence," says Glyph. But it is irresponsible to make a worthy piece of software, gain users, then disappear without a word.

We also have a responsibility to protect our personal information security; for example, a Python project maintainer must protect her PyPI account so her users know they won't be hacked when they install her package. That responsibility is shared with the community's infrastructure maintainers, and Glyph cites PyPI as one of the best modern examples. "It doesn't get enough credit because of Python's checkered history with packaging," he says, "but the way Donald Stufft thinks about practical information security, and the other folks who work on PyPI as well, and the resources the PSF has invested there," have laid a foundation for securely distributing open source Python.

And finally, many of us set a low bar for the quality of code that we release: if the project scratched our own itch, we might as well open-source it. In Glyph's opinion, we must more carefully consider the impact of the code we give away, because we can't predict how it will be used. Glyph knows that many of the largest sites run Twisted somewhere in their stack, and he feels the responsibility keenly.

"A lot of our software completely escapes its originating context," says Glyph. The author might intend to release a mere prototype, but downstream packagers come to depend on her code, and other programmers even farther downstream might not know they depend on it at all. Of course, software users share some responsibility for auditing what code they use. "This responsibility is not black or white," says Glyph. "There's small tradeoffs and fractional proportions. It's not 100% yours or not, but you've got to think about it."

Monday, July 24, 2017

2017 Bylaw Changes

The PSF has changed its bylaws, following a discussion and vote among the voting members. I'd like to publicly explain those changes.

For each of the changes, I will describe  1.) what the bylaws used to say prior to June 2017 2.) what the new bylaws say and 3.) why the changes were implemented.

Certification of Voting Members
  • What the bylaws used to say
Every member had to acknowledge that they wanted to vote/or not vote every year.
  • What the bylaws now say
The bylaws now say that the list of voters is based on criteria decided upon by the board.
  • Why was this change made?
The previous bylaws pertaining to this topic created too much work for our staff to handle and sometimes it was not done because we did not have the time resources to do it. We can now change the certification to something more manageable for our staff and our members.

Voting in New PSF Fellow Members
  • What the bylaws used to say
We did not have a procedure in place for this in the previous bylaws.
  • What the bylaws now say
Now the bylaws allow any member to nominate a Fellow. Additionally, it gives the chance for the PSF Board to create a work group for evaluating the nominations.
  • Why was this change made?
We lacked a procedure. We had several inquiries and nominations in the past, but did not have a policy to respond with. Now that we voted in this bylaw, the PSF Board voted in the creation of the Work Group. We can now begin accepting new Fellow Members after several years.
Staggered Board Terms
  • What the bylaws used to say
We did not have staggered board terms prior to June 2017. Every director would be voted on every term.
  • What the bylaws now say
The bylaws now say that in the June election, the top 4 voted directors would hold 3 year terms, the next 4 voted-in directors hold 2 year terms and the next 3 voted-in directors hold 1 year terms. That resulted in:
  1. Naomi Ceder (3 yr)
  2. Eric Holscher (3 yr)
  3. Jackie Kazil (3 yr)
  4. Paul Hildebrandt (3 yr)
  5. Lorena Mesa (2 yr)
  6. Thomas Wouters (2 yr)
  7. Kushal Das (2 yr)
  8. Marlene Mhangami (2 yr)
  9. Kenneth Reitz (1 yr)
  10. Trey Hunner (1 yr)
  11. Paola Katherine Pacheco (1 yr)
  • Why was this change made?
The main push behind this change is continuity. As the PSF continues to grow, we are hoping to make it more stable and sustainable. Having some directors in place for more than one year will help us better complete short-term and long-term projects. It will also help us pass on context from previous discussions and meetings.
Direct Officers
  • What the bylaws used to say
We did not have Direct Officers prior to June 2017.
  • What the bylaws now say
The bylaws state that the current General Counsel and Director of Operations will be the Direct Officers of the PSF. Additionally, they state that the Direct Officers become the 12th and 13th members of the board giving them rights to vote on board business. Direct Officers can be removed by a.) fail of an approval vote, held on at least the same schedule as 3-year-term directors; b) leave the office associated with the officer director position; or c) fail a no-confidence vote.
  • Why was this change made?
In an effort to become a more stable and mature board, we are appointing two important positions to be directors of the board. Having the General Counsel and Director of Operations on the board helps us have more strength with legal situations and how the PSF operates. The two new Direct Officers are:
  1. Van Lindberg
  2. Ewa Jodlowska
Delegating Ability to Set Compensation
  • What the bylaws used to say
The bylaws used to state that the President of the Foundation would direct how compensation of the Foundation’s employees was decided.
  • What the bylaws now say
The bylaws have changed so that the Board of Directors decide how employee compensation is decided.
  • Why was this change made?
This change was made because even though we keep the president informed of major changes, Guido does not participate in day to day operations nor employee management. We wanted the bylaws to clarify the most effective and fair way we set compensation for our staff.

We hope this breakdown sheds light on the changes and why they were important to implement. Please feel free to contact me with any questions or concerns.