It’s been four days since I issued my Tuit Challenge for the upcoming 2023 Evergreen International Conference, and two people have already signed up to try out my tuit cookies on hackfest day! Many thanks to Andrea Buntz Neiman and Jason Stephenson for their commitments for contributing during the day!
We are also well on our way to giving conference goers the opportunity to permanently damage their hearing by listening to me sing karaoke. On a more positive note, we are nowhere near the point where Rogan gets to pick the song. With the names of Burt Bacharach and the Beastie Boys coming up in the community IRC channel over the past week, I can’t say I’m disappointed we’re so far away from meeting that particular goal. I don’t think I fully appreciated the full gamut of musical styles that could be foisted upon me when I came up with this challenge.
To help build excitement for the conference and for my tuit cookies, I am planning to post a fun fact about tuits each week until the conference begins. Spoiler alert: there are no facts about tuits out there, so I will need to get a little creative. I also hope to incorporate some lessons I’ve learned about open-source communities into these posts and may even touch upon some topics that will come up in my “Burnout in Open Source Communities” presentation.
Fun fact about tuits #1
I first learned what a tuit was eleven years ago during an Evergreen conference presentation from Laurentian University Associate Librarian and former Evergreen core committer, Dan Scott. During his “Ecology of the Evergreen Developer” presentation, Dan defined tuits or round tuits as “a fictional device that would enable the holder to accomplish all tasks that simply require time; as in ‘When I get around to it'”
Before I go further, I’m going to talk a little about Dan Scott. When I first joined the Evergreen community in 2010, Dan was an incredibly active member of the community and was already a member of the core team of committers. Although he did indeed contribute a bit of code and documentation to the project, I consider his most valuable contributions to be ones where he helped with the creation of processes and community infrastructure that continue to be in place to this day. As a person who was new to the world of OSS, I looked to Dan as a model of what it means to be a good open-source citizen. He was a strong advocate for transparency, for quality assurance processes, and for building a community where multiple voices could be valued and heard. He also set strong expectations for other community members, reminding them of the importance of giving time to the work that needed to be done to support the project. After spending some time at Google as a mentor in the Google Summer of Code program, he also came back with suggestions on how to welcome new contributors in an open-source project and incorporated those practices into his own interactions with other community members.
Dan also had a direct impact on my own involvement in the Evergreen community, nominating me to serve on the Evergreen Oversight Board when the body held its first election back in 2012. As I became more active in the community, Dan’s involvement waned and, like me, he is no longer a formal part of the community. However, his impact on the project during its early years will continue to be felt for as long as the project continues. I consider it a privilege to have gotten to known Dan during the years we worked together on the project.
The “Ecology of the Evergreen Developer” presentation in which Dan explained the meaning of tuits was an attempt to make end users more comfortable participating in the developer community, explaining the processes that go into making an Evergreen release and the language used by the developer community.
Thinking back to this presentation reminded me of the importance of “bridges” in open-source communities, particularly in a community that has as much end-user involvement as the Evergreen community. I first heard about the idea of these “bridges” a few months after Dan’s presentation when Dan and I traveled to Mountain View, CA, along with a couple of other Evergreen community members, to participate in a Google Doc Sprint. Facilitator Allen Gunn described bridges as the people in an open-source community who can easily talk to end users and developers alike and help facilitate communication between these two groups of people. Basically, a bridge helps end users and developers better understand each other.
I grew up in the restaurant business, with my father being the chef and my mother front of house manager in the restaurant they jointly owned. I’ve often thought of the bridge in an open source community as serving the same role as the waitstaff or front of house manager in a restaurant. There’s a reason why customers don’t directly interact with cooks or chefs in most restaurants. These professionals may have a talent for making food taste great, but they aren’t always the most pleasant people to talk to, especially if there is a complaint about their art. Both the customer and chef have the same goal – a great meal – but there may be times when they disagree on how to reach that goal. It’s up to the waitstaff to communicate to each of these people, with a smile plastered on their face, to ensure that this goal is achieved. It may require that they strongly advocate on behalf of the customer in the face of an angry chef or delicately deliver bad news to the customer when a request is undoable or unreasonable. It may not always lead to a happy result, but the odds of success are greater than if the customer and chef were left to communicate with each other.
During my nine years in the Evergreen community, I spent many hours serving in the role of a bridge or, as one of my NOBLE colleagues once called me, a developer whisperer. Dan was doing the same as he explained the language and processes used by developers at that long-ago conference, and there are many others in the community who serve in this critical role. Of course, librarians have their own strange language too, and I’ve seen many cases where they’ve stepped up to the plate to talk to new and not-so-new sys admins and developers about MARC records and other concepts unique to libraries.
Like the customers and chefs at my parents’ restaurant, end users and developers in the Evergreen community share the same goal: to build stable, robust, flexible, secure and user friendly software for libraries. But they may not always agree on what that means or how to get there. Or, maybe they agree, but they don’t fully understand what the other person is saying. The bridge can help sort through those conversations. Serving as a bridge can entail many hours sorting through implementation details to get a solid understanding of what those details will ultimately mean for end users and then finding a way to convey that information to those end users. When communicating end-user needs for a new feature, a bridge will carefully think through every scenario and write complete development requirements, with mock-ups and user stories that describe how a feature will be used. This front-end work may take a lot of time, but it saves future misunderstandings and corrections. It also requires dogged and persistent advocacy for things like consistent UI and click reduction to improve the end user experience. These discussions can sometimes get messy, but, in the end, they result in better software for everyone.
At last year’s American Library Association (ALA) annual meeting in Washington, D.C., a conversation on open-source software arose during Marshall Breeding‘s Executive Perspectives panel, probably because there were two representatives on last year’s panel from companies that work in open-source software. During the discussion, Index Data‘s Sebastian Hammer described open-source projects not as being about kittens and beer, but as being about conversations. This comment resonated with me because nearly ever feature or bug fix I shepherded into the project began with a conversation that carried through the entire implementation of the contribution until that final piece of documentation for the new feature or bug fix was published. In some cases, the conversation continued to go on as others found problems with it or found ways to enhance it. If it’s true that open-source is all about conversation, then it is critical that communities encourage those who can serve as bridges, support them and try to keep them around to keep those conversations flowing.
Tuit Challenge Dashboard 4/1/2023
- Days until hackfest: 25
- Days until deadline to commit to a hackfest project: 20
- # of hackfest commitments: 2
- # of additional commitments required for karaoke: 6
- # of additional commitments required for Rogan to pick the song: 14
- # of tuit cookie batches kmlussier must make: 1
- Musical artists mentioned in the context of karaoke in the community:
- Burt Bacharach
- Beastie Boys
- Musical artists that have not yet been mentioned in the community (in case somebody [Rogan] is looking for ideas):
- Grateful Dead
- On a scale of 1-10, level of kmlussier’s anxiety at the idea of singing karaoke: 3