Culture track

We want to know what special sauce you use for interpersonal insights!
What makes open technology and culture communities effective? Demonstrate how you motivate people to work together well. Example topics from the past include “’Why did you do that?’ You’re more automated than you think.” and “Seven Habits Of Highly Obnoxious Trolls.”

Sessions for this track

Imagine a place where Ruby meets Music, its called MAGIC LAND.
Music is not a lot different from programming. In this talk we will see how.
I will talk about this amazing piece of open-source software called SonicPi. SonicPi is a new kind of musical instrument. Think about it, you write code to make music. And it gets even better, code is written in a ruby DSL. Also I will talk about notes, samples, synth and other musical things SonicPi lets us do it.
Don't worry if do not get these terms. When I started, I did not either. But at the end of the talk, you will know how to make music.

One measure of health in open source projects is a growing contributor community. In 1975, Fred Brooks published The Mythical Man-Month, in which he noted that adding manpower to projects slows the release of software. If Brooks’ Law holds true, are growing open source projects doomed to fail? Or can we reconcile the ideas that more contributors are both beneficial and detrimental?

Depending on what sector we come from, the words “community organizing/management” might invoke images of canvassing with flyers and clipboards or moderating online forums and high-fiving code contributors. Regardless, when we coordinate volunteers, email program participants, and chat with community members via social media, we are ultimately organizing and developing community. Whether your supporters are contributing content, volunteering, participating in forum discussions, or engaging on social media, you can play an important community management role.

The free/open source software movement is over thirty years old, and has gone through a number of changes in that time, spawning projects large and small (including OpenConferenceWare, which runs this site!). If Free Software is the first generation, and Open Source is the second, current efforts toward creating an inclusive and sustainable world make up a third generation that we can start to form into a broader plan.

I've been making a documentary film about accessibility for almost a year now. What I've realized is that film is fundamentally hard to access. Let's talk about what that means for culture, creators, and consumers.

Good engineers write good code, but the best engineers raise the skills of their junior colleagues, too. If you're a senior engineer, you must learn to mentor new hires. Besides, great mentors are critical to the careers of women and minorities in tech. I have failed at mentoring, then succeeded. Learn from me and march to mentorship triumph.

As open source software developers and community maintainers, fostering an inclusive community and giving contributors the tools they need to succeed is incredibly important, but not always easy. This is especially true when you have a complex distributed codebase and contributors without a background in software development. Through our attempts to enable our contributors we’ve encountered many challenges and iterated on many solutions with varying levels of success. Our hope is that by sharing the stories of our successes and failures, as well as the lessons we learned, we can help other community maintainers lower the barrier to entry for contributors.

If you're caught in a job or a project where you simply can't convince your colleagues or organization to treat you with respect, it often feels like you're in a maze with no clear way out. (Un)fortunately, you're not alone. There's no universal solution to navigating a toxic or abusive workplace, but there's power in finding a theoretical context, sharing our stories, and learning from each other. Come learn about the options of voice, loyalty, and exit, and hear the stories of others who have had to make hard choices.

Julia Nguyen leads if me, an app to share mental health experiences with loved ones. In doing so, she has explored her insecurities with mental illness, learned how to engage diverse contributors, and developed better software practices with Ruby on Rails and JavaScript. She’ll share the lessons she has learned from transforming a passion project into an open source project.
Inclusion takes on many forms in an open source project, including supporting contributors from all types of backgrounds, being empathetic to their project goals, and trusting them to take lead. As a mental health project, if me must also accommodate its contributors who face their own mental health challenges. All open source projects should do the same. Managing people is just as important as managing technical contributions in software.

I gave a similar talk at LibrePlanet 2015 and would like to reprise it with updated information on the current state of FOSS for Cultural Heritage. I'd like to discuss how to get involved with FOSS projects that are related to the Cultural Heritage space and what kinds of projects currently exist. I'll end the session by talking about what kinds of projects could and should exist as well as community building and awareness in FOSS for Cultural Heritage Organizations.

Bring your stiff shoulders, sore wrists, tight hips, aching back, and busy mind and explore how Yoga can help bring you relief, rest, and focus. Leave with ideas on how to incorporate 5 minutes of practice into your busy day to care for your body and mind.
This class is accessible to all levels of ability.

When you run an online service, you always hope you won't have to deal with abuse. But it's inevitable, and many situations aren't clear-cut as you might wish. Some examples of abuse are obvious, but this talk explores the grey areas and messy questions: what content should you consider a violation of your Terms of Service, and how do you handle it when it's reported to you?

Like many young Muggles of the early 00's, I dreamed of receiving my Hogwarts letter. But re-reading the series with an eye toward learning lessons about creating a positive learning environment, it's clear that Hogwarts School of Witchcraft and Wizardry contains some unfortunate lessons in what NOT to do. When it comes to crafting an environment that encourages asking questions, fosters cooperation, and ensuring the success of its developers -- I mean, wizards -- we can learn a lot from the mistakes of the Hogwarts faculty. In this magical talk, you'll learn how to be a better mentor and help your workplace become a place where your junior developers can flourish.

Running a tech non-profit, especially in open source, is a lot of work. So much work, in fact, that in my six years as part of Wikimedia Philippines, I will admit to one of my biggest secrets: I have run my organization into the ground. Luckily for us, however, we've been really fortunate to be able to rebuild the organization from the ground up. Here's some of the lessons we've learned over the course of that process, and how you can avoid making the mistakes we made as you either form or build your own organization.

Getting people started is easy. Sustaining people through is not. Let's talk about the ways the Open Source community can help people beyond the beginning steps, in the context of public library programming and staff development.

This talk will cover the fascinating things happening in the open source diabetes tech (D Tech) space (think the Glucosio Project and Nightscout Project) and will emphasize the importance of open source in improving the health outcomes of people with diabetes.

This talk will discuss how a closed loop in education—across all grade levels and disciplines—contributes to the stagnation of a profession and how an open source approach and platform is necessary to break the inward cycle of our current pedagogy. It will also show examples of collaboration in the creation of curricula leading to the generation of new, innovative pedagogy and review current methods for educators to open source and call for new methods and platforms to aid educators.

For every average person that finds your product what they want, there is a person outside that average that wants to use your product. They might even be able to use your product, if there was a way to make it work for them. Outliers are useful for your design, if you harness them properly.

In this talk, we'll examine the pressure in the tech industry to participate in work-related extracurriculars like side projects and meetups. We'll analyze where these expectations come from, what they're actually getting at, and talk about ideas for progressing in our careers without losing sight of the things in life that make us happy outside of work.

Social media has tremendous power to enrich our lives - but social media services are largely controlled by private companies. An alternative is to replace centralized services with federated protocols. HTTP and email are examples of federated protocols that demonstrate that federation not only works, but can thrive and give rise to cultures and technologies that the protocol authors never imagined. Poodle is a prototype that I hope will bring those qualities to social media.

Open source (like many fields) rewards people who are confident and even a bit pushy. So we give talks encouraging folk to get over imposter syndrome, lean in, say yes to more things. But self-improvement shouldn't focus only on our most vulnerable members, but also our most powerful. So let's talk not about saying yes, but about hearing no. Learning to take no for an answer can transform efforts such as security, diversity and mentoring where we have few experts or volunteers and great need. Let's talk about accepting "defeat" with grace, and how to take "no" for an answer while still moving forwards.

While the increased use of technology has in some ways improved the lives of those with disabilities, there is a gap that still needs to be filled. Uncaptioned or poorly captioned videos leave the deaf and hard of hearing community out of the loop, untagged photos leave blind users unaware of integral information, and poorly coded webpages are too much of a hassle for individuals using screen readers.
But what if this was this was different? What if we thought about all of the potential users of our technology and developed programs intentionally allowing access for everyone? How could we make a programmer’s work truly inclusive, truly open to everyone?
Experiential learning often provides those ‘a ha!’ moments, so together we’ll enjoy some mis-captioned videos, have a ‘listen-along’ to what a screen reader sounds like when a page is not coded correctly, and take a look at the end users’ experience when software is not programmed with a disabled audience in mind. Then, we’ll talk about what we can do to improve the current offerings and answer, “what next?”

The Open Source and Free Software community is no longer simply a patchwork of hobbyist communities. Our change and growth brought many advantages, but some disadvantages too. We now operate in a microcosm not unlike the larger USA and international political climates. Hear the story of how it operates from an political insider.

Emoji is taking over the Web! We will look at how the phenomenon of Emoji has taken the Web by storm, explore how people are using Emoji on their favorite platforms and implications. We will also examine how these online platforms are benefiting from Emoji.

A lot of people enjoy contributing to Open Source projects. And Open Source projects love contributions. And yet I keep seeing newcomers struggling to contribute and project maintainers struggling to find contributors. What’s the catch?
There is a gap. A gap between the desire to contribute to a community and the ability to find one. A gap between what contributions are welcome, and what people think is wanted. A gap between what people wish they could contribute, but don’t know how, or are afraid to try.
In this talk, I’ll share our learning from building the Hoodie Community, which is recognized as one of the most Open Source’s most diverse and inclusive.

In the early years of easily distributable software, technical writers and the documentation that they produced were a crucial part of the software development process. Why? What kinds of contributions did they make, and what might their close cooperation with the programmers of their day teach us about how to manage open source projects better today?

Think of a shibboleth as a proverbial line in the sand that determines who belongs and who is an outsider. There are a lot of arbitrary shibboleths in programming. Text editors (emacs vs. vim vs. sublime), paradigms (object-oriented vs. functional), languages (everyone vs Java), type systems, are all topics of… to put it lightly, “vigorous conversation.” In set theory terms, the developer community does not do enough to encourage seeing different developer groups as unions instead of intersections. To a newcomer, this situation sets up too much of a danger of alienation. If someone makes fun of the language that you use to learn how to code, then you’re less likely to want to keep learning.

How do you deal with a free software project that has been ongoing for many years? What happens when the original designers moved on long ago and even the elders don’t have all the answers? This session will examine how to work with existing precedents to drive evolution of the project.

Proposals for this track

Imagine a place where Ruby meets Music, its called MAGIC LAND.
Music is not a lot different from programming. In this talk we will see how.
I will talk about this amazing piece of open-source software called SonicPi. SonicPi is a new kind of musical instrument. Think about it, you write code to make music. And it gets even better, code is written in a ruby DSL. Also I will talk about notes, samples, synth and other musical things SonicPi lets us do it.
Don't worry if do not get these terms. When I started, I did not either. But at the end of the talk, you will know how to make music.

Established OSS projects have complex communities that must (at least) try to work together. Presentation of my experience with OpenEMR's and other projects successes and failures and interact with the audience to share their own experiences.

Much of the interest in MindRider stemmed from Spencer Lowell's great photo in Wired UK. Since it came out, many people have sent me great comments, saying things along the lines of
"Women represent!" or
"POCs (People of Color) represent!" or
"Filipinos represent!"
This has meant a lot. Women and people of color are still underrepresented in both tech and cycling domains, and I've come to think of the MindRider photo, and the ensuing response, as a personal counterbalance to the aggressive, intolerant, exclusionary discourse that still plagues these domains, and especially plagues the startup sector that overlaps both. Some people call this "brogrammer talk." I've witnessed it in my time at MIT, and while I've noticed that most people don't talk or think this way, the loudness of the intolerant minority can have insidious, stressful effects on the rest of the community.

There is a secret recipe for successful civic hacking. As a Code for America brigade captain for over three years, organizer of numerous civic tech events and hackathons, and authoring a book about open source, open government, and open data, I have a tremendous amount of knowledge to share about civic hacking.

Many people create projects with amazing technical prowess, only to see it fail to gain traction. We wonder "I thought this was clearly the best solution, why aren't people using it? Did I miss some bugs? Is it too slow? What went wrong?" The answer usually isn't technical, it's documentation or community related. This talk will teach you all the non-technical things your project needs to gain traction.

Copyleft, and the GPL in particular, are under threat. The treacherous political climate of for-profit open source cooption has changed the nature of our community. Can copyleft continue to be an effective tool to defend software freedom, and if so, how?

The desktop application market has long languished. Even today there is no way to understand the strength of the GNU/Linux desktop application market. This talk will focus on creating a measurable desktop market by focusing on changing the application distribution model using GNOME xdg-app.

Despite the media attention given to the diversity in tech problem, many technology practitioners don't see how a lack of diversity affects their daily life. So, it is not surprising that they neither understand the magnitude of the problem nor how they can fix it.
However, the principles and language of debugging, something technology practitioners understand well, can be used to help them understand diversity and their role in solving the problem. So, technologists already have a set of terms that they can use to tackle diversity. They just need to know how to apply those terms in order to effect positive change. These terms are expected behavior, tracing, refactoring, and sample code.

Contributing to open source is rewarding in terms of the satisfactions you get while you help the open source community to grow as well as the new things that you get to learn. If you go on discussing about contributing to open source most of them find it intimidating. Most of them are scared of contributing to open source projects. Most of them think that it is too tough to get in, too tough to get started and they won’t be able to do it.
There are a lot of myths about the difficulty level of getting started with contributing to open source. With this talk I would like to break the myths and tell the truths around them.

The principles behind building reliable distributed systems and gracefully managing changes in them turn out to look a lot like the principles behind building psychologically safe communities. In this talk, I'll explain some of the basic principles behind site reliability engineering and how they relate to feminist and social justice ideas. This talk assumes no prior knowledge of site reliability engineering.

In many open source communities, privilege is rarely discussed. While it is not an easy topic to talk about, it is an important subject to explore if we want to make sure open source is truly open to everyone. After exploring sources of privilege and learning strategies to deal with it, we can all be better equipped to take action to improve our open source communities for the long run.

It's possible to do Support work while knowing absolutely nothing about the underlying architecture. Support doesn't necessarily know why the product works, or even what language it's written in. It can be super tempting for an engineer to think that well, if these support people really had the competence and capacity to understand how the thing worked under the hood, then they'd be engineers and not mere support people, but that's a bad trap to fall into. Sometimes Support people are engineers in their own right, but a Support person with no computer science training can be an expert on the user interaction surfaces of the product and reproduce a result that has been baffling the engineers, even with no knowledge of the mechanism by which the bug is happening. It's helpful to give Support enough information about the architecture to have a better starting point for asking the user for details and trying approaches to replicate the problem.
It can be tempting for Support to think that any given member of Engineering understands the entire breadth, depth, complexity, and interconnectedness of the entire product simultaneously at any given time, but this is a trap! A good amount of time Engineering has no clue in the slightest about what is going on in another branch of the product, and in a sufficiently complex codebase, there can be millions of lines of code that a single particular engineer has never touched or even heard of. Or it's been long enough since they worked on that part of it that they would have to take several hours of very hard study in order to figure out what's going on. In particular, sometimes in a bug report, Engineering can say "Okay, I see what *part* of the code the user is causing to fire, but I haven't the FOGGIEST idea how the customer actually got that to happen." It's very important for Support to list out every single step (even the ones that seem obvious) that leads to the error occurring.

Being a great developer is much more than technical know-how. Empathy, communication, and reason are at least as important, but are undervalued in our industry. We'll examine the impact these skills can have and how to apply them to our work.

It is necessary a waste that we seldom make the most of free resources online. We spend a lot of budget buying the software which is replaceable and deal with problems in an ineffective way. That is why we start this project to help others in an efficient way.

The goal of this working group strikes deep at the heart of problems in open source software. We hear the stories of contentious and dramatic flare-ups, but not the day to day work people do to make things better. Come learn what it's like and what it takes to make a difference in OSS culture.

Growing concerns of media preservation mean a surge of new digital libraries. However, digital preservation is more than just photos and video; it's also interactive software: art creating new art. We will explore the problem of preserving software; past, present, and future; and why it is hard.

How to make young developers contribute to open source? How to find talent for your company? How to help underrepresented groups to start a professional path on programming?
Can we tackle all of these at the same time? Yes! and here's how

Despite all the attention and buzz, Machine learning(ML) is woefully overlooked in the community of free and open source technology. In this presentation, I will examine the still prevalent proprietary legacy of ML, introduce the current open source stack of ML development and applications, and evaluate new proprietary attempts entering ML. Then, I will share with you the strategy recipes that we may need, in a battle to keep the booming field of ML free and open source.

I first knowingly witnessed the "Maker Movement" in 2010, heeded its siren call by joining the MIT Media Lab in 2011, and became disillusioned later that year. But I've been stubbornly making--and critiquing the notions of Making--ever since.

What can you do when someone submits a bad patch to your project? To begin, we have to understand why people hunger to contribute code: they're fans. You hurt fans' feelings when you reject their patches, but you hurt your project if you accept them. You can get out of this bind! Give your fans other ways to be recognized. Showcase their plugins in your project’s wiki, or rewrite their patches while giving them credit, or feature their related projects on your site.

Blogging is a great way for developers to share with the community the kind of things they've been learning and working on. By keeping a regularly updated blog, we force ourselves to continually evaluate the things we're learning, while sharing these ideas with the community at large.

Open Source is one of the foundation pillars of our industry. You probably use the power of open source software every day: in the code you write, the tools you build with, the servers you deploy to.
But perhaps it’s not quite the stable foundation we were hoping for? This talk will cover the various strengths and weaknesses of both open source and our reliance upon it, so we can trade in our assumptions for a greater awareness of the issues. Then together, we can find a path towards a more sustainable open source ecosystem.

Mental disorders are the largest contributor to disease burden in North America, but the developer community and those who employ us are afraid to face the problem head-on. In this talk, we'll examine the state of mental health awareness in the developer workplace, why most developers feel it isn't safe to talk about mental health, and what we can do to change the culture and save lives. Attendees will leave with 5 things they can do to make their workplace safer for those dealing with mental health disorders.

When you are trying to transition into tech, it helps to be part of an open source community that welcomes people from all types of backgrounds and experience-levels. If you are a beginner programmer and underprivileged, the search for the right tech community can be a daunting experience. You may be systematically excluded from participating in some communities by gatekeepers. As a programmer who comes from a marginalised community, allow me to share with you the story of how I found a programming community that welcomed and helped me to overcome the high barrier to entry in tech. This talk aims to encourage everyone to do their bit to create inviting communities for the underprivileged.

With the growth of open source comes the need for more conferences, meetups and hackathons – you name it! These events give community members the opportunity to interact face-to-face to solve problems, come up with new ideas, or even just to chat and get to know each other better. But, the question is – how do we get developers, users and contributors from open source communities to these events?

The primary reason I was able to make career pivots at Intel was due to my connections to the Women at Intel network. Through this network I was referred to career counselors, business contacts, and the technical experts I needed to move my career ahead. As an FTM, my inbox is still filled with opportunities from women in tech groups, but now when I see these emails I wonder if I will be welcomed or not. A recent email I received said specifically "if you are female please attend." As a person who now identifies as male, I find that my connection to the community that supported me for the entirety of my career is now becoming tenuous.