How your company can build and keep community trust

Originally published on opensource.com.

This is Part 2 in a series of articles on community management best practices. Read Part 1: Practical business reasons to support open source communities.

If you are part of an organization looking to get into the community-support game, you would do well to tread carefully and deliberately. Communities, particularly at the start of your involvement in them, can be delicate and fragile things. Stomping in there with big words and big plans and big brand engagement will cause a lot of damage to the community and its ecosystem, often of the irreparable sort.

Before your organization sets forth on the community path, take the time to do research first. Learn who the members of the community are, and about the social dynamics between them. Learn the community’s jargon, but not in a “How do you do, fellow kids” sort of way. Listen to what the community members discuss, what concerns them, what they enjoy, what they’d like to change. A week or two of research can help prevent many otherwise non-obvious missteps once you start engaging with and participating in the community.

Once you finally do take the plunge into community support, being open and sincere about both your intentions and the role you will be playing in the community is vital. As this is a community coalesced around a project or product on which you rely, the community likely will welcome a representative from your organization into the fold. But dissembling and pretending not to be associated with the organization will inevitably be discovered and will cause ill-will on the part of the community members.

First build trust

When supporting a community, initially building trust in the members of that community is important. Without trust, you will never be able to guide, direct, or grow a community. It will not matter that the community formed around one of your organization’s projects or products. If community members do not trust you, you will not be allowed to participate in the community and you will lose all of the business benefits of that. Furthermore, the community may turn from your product/project entirely.

The actions that build trust within a community are the same ones that build trust between any people or organizations:

  • First listen. Listen, listen, listen. Listen more than you speak. The community has things to say and wants to be heard. Take the time to listen carefully.
  • Then speak. When you do speak, do so to make promises based upon what you have heard. Making the promises is not nearly enough; you also must deliver on them. If you’re not making promises when you speak, you should be asking for feedback and input and then, again, taking action upon this.

Community communication

Another important reason for you to speak rather than listen is the unfortunate situation of negative interactions and experiences within the community. If not for the sake of the community, then for the sake of your organization’s reputation, you must maintain a policy of zero tolerance of abuse.

When speaking with the community, you must always be open, sincere, and honest, brutally so if necessary. Part of this may include owning up to your mistakes, communicating what went wrong (and what’s being done to correct it), and making sure it never happens again. This is more than just PR; it’s building, reinforcing, and validating the trust and relationship you’ve established with the community.

This level of listening, delivering, and communication can form a strong foundation of trust that will get your organization and the community through both good times and bad. When both sides trust and support each other, that’s when the real magic begins to happen. Furthermore, that’s when other people, viewing the community from the outside, start seeing that magic and want to be a part of it. A strong, vibrant, and trusting community practically builds itself. All it needs it an understanding hand to help guide it and to keep the negative influences and personalities—which find their way into every community—from taking root.

That guidance, and building and maintaining trust, can be a full-time job. Organizational interaction with a community requires a lot of hands-on, high-touch, intimate and open work, otherwise community trust is lost, and community members will turn away from the project/product and the organization. This work is the purview of specialists, people who have invested the time and effort to become intellectually and emotionally familiar with and to the community. These are people who become trusted members of the community and work for the organization as advocates for the community to help provide maximum benefits to both sides of the equation. These people are often called community managers, despite the fact that most of the management that they have to do is upward and internal to their organization, rather than within the community.

A good community manager is knowledgeable of and trusted by the community, so little management is required on that front. What is more often the case is that the organization for which they work does not fully understand the complexities and benefits of the work that the community manager is performing and will—intentionally or not— obstruct or attempt to control the community. This puts the community manager in a difficult position, where they are forced to explain diplomatically the counter-productive actions of the organization to a perplexed community, while also trying to explain the benefits (at risk of being lost) of community support to an organization that may not have thought such things through prior to establishing a community support program.

Stay tuned for the third and final article in this series, coming next week.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.

Practical business reasons to support open source communities

Originally published on opensource.com.

Recently I’ve had several conversations with open source friends and colleagues, each discussion touching upon—but not directly focused on—the subject of why a company would/should/could support a community around a project it has released as free/open source, or more generally to support the communities of F/LOSS projects on which they rely. After the third one of these conversations I’d had in nearly as many weeks, I dusted off my freelance business consulting hat and started mapping out some of the business reasons why an organisation might consider supporting communities.

In this post, I’ll look at community from a business perspective, including the effect community can have on an organisation’s bottom line. Although there are communities everywhere, I’ll approach the topic—meaning, communities, their members, and their contributors—from a free/open source perspective. So please stick around, and maybe you’ll learn ways to communicate the importance of community to your organisation.

(Also, be sure to check out my list of 16 resources for measuring open source community ROI.)

What we mean when we talk about community

First, let me explain what I mean by community. A community is a self-organized collection of people sharing a concern or interest. Although it’s possible to build, grow, and manage a community, this concept of self-organisation is important for providing and maintaining the vibrancy that comes with a strong community. Strong communities are composed of people who self-identify as members of the community, not those who are assigned or forced into it. Members may join or leave the community at will. The members of a community retain complete agency as to their initial and continued membership.

Why would a person become a member of a community? Some will drop in to acquire help for a problem they’re having, but merely dropping in does not necessarily mean a person identifies as a member of the community. Those who return, however, have at least started this self-identification process. Something they experienced on their initial visit convinced them that this is a group with which they’d like to continue to associate. Perhaps they return because of the social dynamics. Perhaps it’s for the shared affinities and inspiring conversations. Perhaps it’s for the friendships they are building. Whatever the reason, a community is similar to so many other things in life: First impressions matter. A community environment in which people do not feel heard, do not feel appreciated, and do not feel comfortable leads to the erosion of the trust and bonds that allow a community to thrive, in addition to increased ill-will toward those who ostensibly claim management over the community.

Communities, fundamentally, are people. Typically the community “personality” is an amalgam of the personalities of the most prominent members. Thus, if the personality skews too far toward the negative, the community will develop a reputation as being negative and unhealthy. One role community manager(s) play is to help shape and guide the community’s personality to build an environment that helps the community members meet their goals, and that benefits organisations that support it.

Business benefits

Why, though, would an organisation invest resources in supporting and guiding a community? How does community-building help the bottom line?

Measuring the ROI of community is tricky, but really no trickier than any other outbound communication effort your organisation attempts. If you’ve ever tried measuring the impact of your organisation’s PR, outreach, branding, and advertising efforts, you know how difficult a task this can be. However, just because something is difficult doesn’t mean it’s not worth doing. Although measuring community support success is challenging, supporting a vibrant community can provide many benefits, both quantifiably and otherwise.

A strong, engaged community gains your organisation the holy grail of marketers everywhere: word of mouth marketing. The community you support will become your street team, spreading word of your organisation and its projects to anyone who will listen. Additionally, an engaged community will provide the most on-time and in-depth market and competitive research. Community members become not only your staunchest defenders, but also a ready, willing, forthright, and cost-effective focus group when the organisation needs to try out new ideas. When you’re out of new ideas, your community will be there as a resource to provide you with the inspiration and experience necessary to spark and potentially implement well-targeted and brilliant innovation, while also pointing you to new tools and best practices to bring that innovation to life more quickly. When that innovation does take off and your organisation is looking to expand, the community it has supported provides a rich and passionate pool from which to recruit new team members, dramatically reducing the time and resources required not only to fill open positions, but also for onboarding once hired.

If word of mouth marketing, market research, product focus groups, and a technical talent pool aren’t enough for your organisation, there are myriad other business benefits to supporting a vibrant community. For example, community members, having been involved in technical development, will likely be early adopters of your latest technology or solutions. The support community members provide each other not only leads to lower support costs for your organisation, it can also lead to lower cost of ownership for the community and those who rely upon it for assistance. And if something does go wrong with your product, for example, an engaged community can provide higher goodwill, tolerance of errors, and public support and PR in times of crisis. Of course, this community support for your organisation only lasts as long as your organisation remains supportive of the community. The moment members of your community sense your organisation is being disingenuous—and they will sense it, on that you can rely—they will rightfully drop support for your organisation, and possibly expose it and all of its flaws.

When considering the benefits of supporting a community, and the metrics for determining success, it’s important to remember that most of these benefits require playing the long game. Trust is not earned overnight, and without the trust of the community, your organisation is unlikely to reap the benefits of supporting and being a part of that community. Most discussions about metrics should be phrased in the context of months and years, rather than days and weeks. Give your program adequate time to get off the ground and start showing results before using those metrics to determine whether the effort is successful.

Enjoy this post? There’s a lot more where this came from. Hire me to help your company be successful with Free and Open Source software & communities.

What to know before you open source an internal project

Originally posted on opensource.com in June 2017.

Before your company makes a project open source, make sure you’re ready for all your new responsibilities to the community that forms around it.

Your company is going to release an internal project as open source. Congratulations! You know your code is ready, but are you ready for all your new responsibilities?

Once a project has been released as open source, your company is not only responsible for the project, but also for the community that will form around it. This often requires changes to the development/build/release workflow. This is not about the code per se; it’s about all the processes and infrastructure that surround the code that make the open source project successful.

Here’s what you need to know and expect before you release your open source project.

Identify your company’s goals

Before you go much further, take a moment to evaluate your company’s goals for releasing the project in the first place. The company will invest a lot of time and effort into preparing this for release—and a lot more in maintaining the project and the community that forms around it. While it’s possible that these efforts are altruistic, it’s more likely that the company expects something for its investment.

Make sure you’re aware of these goals before diving into the project and its community. Taking steps to ensure your company can meet them not only helps the company, it helps free and open source software (FOSS) overall. Companies that don’t know or don’t meet their goals with an open source project withdraw from FOSS participation entirely, and that helps no one.

Understand community expectations

While your company may still hold the keys to the kingdom and decide what contributions to merge and when to bundle a release, all development must be done in the open in communication and coordination with the community that forms around it.

In other words, the project must operate according to established community expectations for an open source project. These expectations include (but are not limited to):

  • All development work—including bug fixes, new feature development, product roadmaps, and discussions and issue tracking about these things—occurs publicly and in coordination and cooperation with the community.
  • All build processes related to the code (continuous integration/deployment, etc.) operate publicly and are accessible by and to the community.
  • The company accepts contributions from the community, where “contributions” means not only code but also documentation, design, product roadmap guidance, governance, and other matters pertaining to the project. All contributions must be reviewed and considered promptly, and feedback must be provided publicly.

Know that community is key

Open sourcing a project creates a lot of work, though in practice it’s usually no more work than proprietary software development. Still, there can be considerable effort required to transition processes and culture to work efficiently and effectively in the open and support an open source community.

If it’s so much work, why do it?

As I mentioned earlier, businesses don’t usually release projects out of the goodness of their heart. They do it because they want to benefit from the community that hopefully will form around the project—but those benefits happen only if the company earns, builds, and maintains the community’s trust.

That trust happens by doing all work in the open and in communication and collaboration with the community. Any fully unilateral or private decisions the company makes will violate that trust and alienate the community. When a community is alienated, they leave (sometimes forking the code to start over elsewhere).

There is no way to benefit from a community that disappears. That leaves the company with a bunch of code that is open but no one uses or cares about, not to mention unable to meet the goals it set when it open sourced the project.

Launch your public issue tracker

Once a project is released, all bug reports—previous and new ones—must be available in the project’s public issue tracker. Here are some things you need to do:

  • Move pre-existing bugs/tickets/issues to the project’s issue tracker.
    • Be aware that moving often requires a script.
    • Before you move anything, review all existing issues and close those that have no real hope of ever being fixed.
    • Make sure to remove any proprietary information from any pre-existing bugs/tickets/issues before moving them to the public tracker.
  • Decide whether to move closed bugs/tickets/issues to the public tracker.
    • This is optional, but it can provide valuable context for future development.
    • Make sure to remove any proprietary information from any closed bugs/tickets/issues you plan to move before making them public.
  • Create a new workflow so all bugs/tickets/issues will be routed efficiently to and through the public issue tracker.
    • Coordinate and train all company staff who report or interact with bugs/tickets/issues.
    • If you use a publicly available issue reporting tool (e.g., ZenDesk), the new workflow must ensure that issues reported there are efficiently transferred to the public issue tracker and the reporting parties (usually customers) still receive the service and information they have come to expect.

Be ready to open your product roadmap

Once a project is released as open source, its development roadmap and all related discussions become publicly available.

  • All discussions and decisions about what goes onto the roadmap (and why) must now be held publicly and with the community’s input.
  • Community feedback should be integrated into the roadmap.

Please note: While the roadmap and all discussions about it occur in the open and with input from the community, unless it has made other accommodations the company may still have the final word on what goes onto the roadmap, when, and why. This should be done in a manner that is respectful of the community the project now serves and supports.

If the public roadmap includes features that interact with or rely on proprietary features, everyone who interacts with the project must be careful not to leak proprietary information in discussions about the public roadmap.

Define the contributions workflow

Once a project is released as open source, all contributions to it must use one public-facing workflow, regardless whether the contribution is from the originating company or the community.

Here’s an example of a typical workflow:

  • A contributor forks or clones the public repository to their own computer.
  • The contributor creates a feature branch of the repository and develops their contribution on that branch. This work, as it’s being done on their own computer, is private.
  • Once their contribution is ready, the contributor submits their contribution back to the public repository. (The process depends upon the version-control system in use and the preferences of the project.)
  • The contribution is publicly reviewed by community members who are qualified to do so (typically known as core contributors). These people then choose to merge, defer, or close (decline) the contribution. If the contribution is merged, it may be to master/head or a different branch, but this depends on the project’s needs and workflow.

Each project must consider and decide upon its specific contribution needs and workflow and make these publicly available in the project’s CONTRIBUTING.md file.

Don’t forget about the build process

The build process is often overlooked when planning to open source an internal project. This is unfortunate, as the build process also happens in the open once the project is released.

Some things to make sure of when opening the build process:

  • There is no proprietary or internal-only fork of the code.
    • If there is, it will betray the trust of the community, who will leave.
    • It will also greatly increase the work required to merge and maintain code.
  • All build processes must work against publicly available code, either the master/head or a stable branch maintained for build (whatever makes the most sense for the project and product).
  • All build artifacts should be made publicly available immediately upon build completion.
    • How they’re distributed after that (e.g., pushed to customers) is a business decision, but the build artifacts (including final binaries) are always publicly available.

Support open discussions of community governance and tooling

Once a project is released, all decisions that impact it or its community must be made in the open, including changes in governance, adjustments to tools such as version control or continuous integration, and changes or additions to communication routes.

This does not necessarily mean that every tiny decision must be sent to committee or requires full discussion from the entire community. Often it is enough to solicit suggestions and feedback from the community and consider them when making decisions.

All final decisions, the reasons behind them, and their expected outcomes must be publicly announced, available, and documented in whatever tracking system the project uses for such things (usually a mailing list plus the documentation system or a wiki).

Open anything else pertaining to the specific project

You get the idea by now:

Anything at all related to the project will need to be done in the open.

Once the project is released as open source, it no longer belongs to “you,” the company, and now belongs to “we,” the community (of which the company is a part). This means the community must be included at all points going forward.

I have time availability for another client! Is it you?

Open sign by caveman92223 on Flickr; CC BY-NDSince I left the Helion OpenStack team, I’ve been helping companies–particularly startups and small/medium businesses–with Open Source, Technology, Community, Business, & the intersections between them. So far it’s been some of the most rewarding work of my professional life. I’ve worked with brilliant people helping them and their companies understand and contribute to free and open source software, as well as develop corporate open source policies.

I’ve been keeping it to one client at a time while I get my practice up to speed. Now I’m ready to ramp it up and add another.

Here’s a sample of what I could do for your company:

  • Counsel and collaborate with company leadership on corporate open source goals.
  • Define corporate open source usage and contribution methods.
  • Develop policies for open source compliance and risk management.
  • Train staff and leadership on meaning of and best practices for releasing and contributing to open source.
  • Analyse processes and provide change recommendations for using and contributing to open source, including community growth and engagement.
  • Develop staffing and hiring plans to support open source development, contributions, and healthy community engagement.

While my primary focus currently is consulting, I’m always open to hearing about full-time positions working in the open source space, be it leading open source software development as director or VP, managing open source program offices, or developing and growing developer advocacy and other community programs.

Contract or full time, I can help your company succeed with open source. Have ideas, leads, or just questions? Drop me a line. Let’s chat.

No, I will not “lighten up”

Here’s a conversation I was in recently. It’s paraphrased and anonymized because I’m not here to name-n-shame.

Person1: Oh hey, $less_popular_project I work on was found to be one of the most secure!

Me: Nice! Good for them. /me boosts signal

Person2: Too bad no one uses $less_popular_project, lol

Me: Not cool. Don’t bag on other projects.

Person2: Lighten up. It’s a joke, jeez.

Had Person2 known Person1 I could’ve let it go as banter between friends, but Person2 didn’t. Person1 was a stranger to them.

I’d intended to leave it at that. I said my piece and pointed out bad behavior, but after thinking about it a bit, no. I’m not done yet. I’m sick of this crap and I’m going to plant my flag in the sand.

Person1 was excited that their project was receiving well deserved recognition for all of their hard work. Person2 used this as an opportunity for a cheap shot and hurtful language.

No matter what the intention (“It’s a joke, jeez.), hurtful language is still just that: hurtful.

There is absolutely no benefit to being mean here. This sort of micro-aggression is masquerading as humor but is amusing only to the teller, not to most of the hearers and certainly not to the target.

Angry cat photo from Flickr user jing.dong, CC-BY-NCFor many years now I’ve been (usually gently) calling people out when they try this sort of thing, but right now I’m going to be more direct about it:

Shaming people’s open source project or community, programming language, platform, editor, framework… This is what bullies do. It’s not funny. It’s not useful. It’s just childish and mean. Knock it the fuck off.

OK, maybe that was more than a little direct. Whatever. I’m tired of third-rate bullies hiding their attacks behind “it’s a joke, jeez.”

I will be firm, polite, and respectful when I do it, but make no mistake that I will call you on your shit and at absolutely no point will I “lighten up.”

At this point someone will chime in with “Yes, see Aurynn’s post, too!” so let me just beat you to that: The very good Contempt Culture by Aurynn Shaw

On the occasional unpleasantness of community

Dear well-dressed lady who walked by as I was clearing the sidewalk of snow and ice,

No, I am not doing this because, as you state, I am “ambitious.” There are myriad things I’d rather be doing right now, not the least of which is working on the article which is due tomorrow.

I am doing this because, however onerous, it’s the right thing to do. The ice I clear from my sidewalk may save one of my neighbors a very unpleasant fall. You, well-dressed lady walking by, must live in a city rather than a community. This is what we do when we live in a community: we help each other.

The same is true in open source communities. Do we want to write documentation? For many of us, the answer is “no.” Do we want to do code review? Hold design meetings? Take the time out to answer user questions? Triage bug reports? Again, the answer usually is “no.” But we do it because it’s the right thing. Because by taking a little bit of time to do something we may not enjoy, we make our little corner of the world a more pleasant and more welcoming place for others. We turn it from a project, from a city, into a community.

Enjoy the cleared sidewalk.

Love from a community member,

Me

Uploading a Video to Internet Archive

I make no secret of the fact that OSCON is one of my favorite conferences. I try to speak at it whenever I can and do what I can to support its community. When I do get the opportunity to speak there, it's one of the most seamless experiences a tech conference speaker could ever hope to have.

Part of that seamlessness includes a speaker agreement which very clearly sets forth the expectations and responsibilities both of the presenter and of O'Reilly Media. My favorite part of that agreement is this clause:

ORM speaker agreement

What that says is that while I agree that O'Reilly Media has the right to sell its own access to the video of my presentation, I retain the right to distribute it for free as I see fit. This is a marvelous clause. It shows a deep respect for the speakers and their investment of time, effort, and sometimes financial expense to create and present the content at the conference. It's great that O'Reilly Media allows the speakers this freedom to distribute their content and is in line with the free/open/libre principles with which O'Reilly has become associated over their many years.

I typically download the videos of my OSCON presentations and make them available on (where else?) Internet Archive. This post will detail how other speakers can do the same. Most of this process will work for most any video to which you have the rights. That last piece is key. Do not upload videos of other speakers' presentations unless they have given you permission to do so.

Download your video

Naturally, before you can upload your OSCON video to Internet Archive you must first download it from O'Reilly. Duh.

One of the perks of being an OSCON speaker is access to the complete vault of that year's OSCON videos. This is a treasure trove of information presented by world-class speakers and technologists. If you haven't checked it out yet, I highly recommend setting aside a few hours to lose yourself in it and fill your brain.

All of these videos are available for download for subscribers to the vault and are entirely DRM-free, just like O'Reilly's books. Feel free to download all of them for your offline use, but please do the right thing and not distribute the ones to which you have no distribution rights.

To download your video, log into your O'Reilly account and navigate to your library. The OSCON video vaults to which you have access will be listed there.

If you have an ad-blocker enabled on your browser, you may need to disable it for the next step otherwise the necessary UI elements won't appear.

When viewing the vault for that year's OSCON, the videos are organized by track. If you don't remember which track your talk was in (I never remember this), you can just pop open all of the track accordions and use your browser's search function to find your name in the list.

To the right of your talk is a nice little download button. Click that, wait for the entire file to come down and, voila!, you have a video. Go ahead and turn that ad-blocker back on now.

Create an Internet Archive account

While, sure, you could upload your video to YouTube, vimeo, or some other free streaming service, in the spirit of open/free/libre and open access I always upload mine to Internet Archive. I used to work at the Archive, so I confess to no small amount of bias here. But who among us can argue with a mission of Universal Access to Human Knowledge? If you upload your video to the Archive you're guaranteed that it will be free (in all senses of the word) and accessible in perpetuity.

Internet Archive is an accredited library, so to upload to it you need a patron account. Naturally, as with any good library, patron accounts are freely available.

To create or access your patron account, vist the Archive and click the Sign In link. From here you can either sign in with your existing patron account credentials or create a new one.

Upload your video

While it's possible to use an API or a script or Python library to upload your file, today I'll describe how to do it using the Internet Archive upload tool.

Click the Upload icon on the Archive front page:

pic of the front page

Click the “Upload files” button on the tool and then drag your file onto it:

pic of the drop here

After doing a bit of parsing on the filename, the tool displays some metadata fields. Many of these are required to proceed:

pic of the metadata form

Enter the appropriate information then click Upload to start the process. The tool presents a progress bar while it does its work.

pic of the progress bar

After the file upload is complete, the display changes to the Internet Archive page for your file:

pic of the item

If you look at the box on the right side of the page you can see that the file is there and available for access. However, it won't be available for online viewing–nor can changes be made to this page–until the file receives further processing. Once that processing is complete, the file will be available for online viewing:

pic of derived item

Voila!

That's all there is to it! Your video is now available for sharing. The Archive will preserve it and make it freely available in perpetuity. At this point you can click the Edit link next to the title and add or change both the metadata and the files in your Internet Archive item.

Open Source Leadership Succession Plan?

I present at a lot of FOSS conferences and therefore have the chance to meet and speak with a lot of FOSS luminaries. These are inspiring people who’ve been working with, for, and on FOSS since the very beginning of the movement and who are still playing absolutely vital roles in FOSS at a leadership level. These are the people we all consult when forming a new foundation, creating a new license, or open sourcing an internal project. Most of the individuals who are working at these conceptual and policy levels of FOSS have been doing it since the beginning and helped to craft the history, the law, the processes, the politics of Free and Open Source software. It will be difficult to replicate that experience and knowledge.

But here’s the thing: We are, each one of us, getting older.

Some day the Tim O’Reillys, the Danese Coopers, the Simon Phippses, the Allison Randals, the Karl Fogels, the Bradley Kuhns, the other luminaries of the FOSS world will want to move on and/or retire. And well they should, as they’ll have more than earned a break for all the service they’ve given FOSS.

As I look around the ranks of FOSS policy leadership, I see all these great people but I see few to no younger leaders. These people have been serving us so well for so long that perhaps we’ve just had no need to supplement them with additional assistance and, in truth, it would be difficult to do so. Which I believe is precisely why we need to start thinking about this now before it’s too late.

So I have to wonder: do we in FOSS have a succession plan for these luminaries upon whom we’ve learned to rely? Are there programs and initiatives for training and mentoring the next generation of FOSS policy leaders? There are plenty of people working to build up the community leaders of tomorrow, but are we devoting enough attention to the policy and legal side of things?

Perhaps we are. I pay a lot of attention to what happens at that level of FOSS but won’t pretend to know everything which is going on. Mostly I just wanted to pose the question to see what thoughts and insights people have about the matter.

OSCON Portland, 2015

Oh, my. My last OSCON trip report is only two posts back. It seems I’ve been rather a slacker on the blogging front. I’ll see what I can do to change that. In the meantime, here’s my OSCON Portland, 2015 trip report.

This was my first OSCON as a Portland resident, which was as lovely as it was exhausting (both: very). When you know as many people as I and live in the city hosting OSCON, your conference lasts multiple weeks as people arrive and depart town. Next year the conference moves to Austin, so I’m grateful I had at least one opportunity to experience a hometown OSCON.

I only had one talk at the conference this year, and that one not scheduled until the final slot of the final day of the conference. It was well-received and surprisingly well attended, considering the other amazing speakers also in that timeslot. This was a talk which my co-presenter and I have given before and which required only minimal edits, which you would think means that I’d have plenty of free time to attend sessions. Unfortunately, that was not the case. For me, this OSCON was filled with meetings and greetings and hobnobbing and discussions. All were with great people and were productive, but it did impinge upon my session attendance.

However, it wasn’t all meetings and I did get the opportunity to see many really great speakers:

  • Presentation Ninjitsu, presented (as wonderfully as you’d expect) by Damian Conway
  • Rolling dice alone: Board games with remote friends, presented by Tim Nugent. Not only was it incredibly entertaining, Tim also did a great job teaching the audience about the philosophy and psychology of games. It also made me wonder whether it’s possible to apply some of his ideas and research on remote gaming to managing remote teams. That could be an interesting talk.
  • How Do I Game Design? Design games, understand people!, presented by Paris Buttfield-Addison, Jon Manning, and Tim Nugent. This talk expanded upon some of the fascinating philosophy and psychology upon which Tim’s touched the day before. Unfortunately I was only able to see half of this session, so I’m very eager to finish watching it when the videos come out.
  • Test Driven Repair, presented by Chris Neugebauer. Chris did a great job debunking the myth that you can’t do TDD on legacy projects. His approach was as useful as it is logical, and his “even one test is better than no tests at all” makes the approach accessible as well. This is one video most every team should watch once it becomes available.
  • Open sourcing anti-harassment tools, presented by Randi Harper. A somewhat controversial session (more on that in a moment) about the tech required to help people avoid online harassment. Both the session and the questions were almost entirely about architecture and technology. It was inspiring to see what Randi has been able to do with a few lines of Perl code, despite the immense burdens inflicted by her own online harassers.
  • As well, I caught every keynote, the videos for which are already online.

And then there were the talks I sorely regret having to miss:

Overall the conference was amazing, yet there was a dark cloud over the final couple days of the event. Some people rich in opinions but poor in manners took umbrage at OSCON accepting Randi Harper as a speaker. These people flooded every O’Reilly Media inbox and phone line they could find with demands that Randi be dropped from the schedule. When that didn’t work, they stamped their collective little princess foot and spammed the #oscon Twitter hashtag with their complaints, making it entirely unusable. Many of us speakers were perturbed by being unable to use the hashtag, so we suggested to O’Reilly that it install Randi’s own project to help improve the signal-to-noise ratio. The organizers of the conference considered their options and found this one to be best, then asked Josh Simmons–the community manager for OSCON–to install the project but only for the duration of the conference. WE SPEAKERS suggested this, O’REILLY ORGANIZERS agreed to it, JOSH SIMMONS became the target for abuse and harassment. He handled it remarkably well, which is a testament not only to his strength but also to his devotion to the community he manages and which supported him in return both in his actions and in his need. I confess, I have largely ignored the movement which caused all of this mayhem and have largely remained agnostic as to their controversy of choice (they simply have not been worth my time). But now that I have seen their methods first-hand, I have formed an opinion and it is a strong one. Pro Tip, kids: If you want to win friends and influence people, don’t attack the innocent lest we all see you for the cruel bullies that you are.

Aside from that, though, this was by far my favorite OSCON I’ve yet attended. The subjects were engrossing, the speakers were world-class, the people were kind, inspiring, thoughtful, and hilarious (often all at the same time). Before this OSCON I was on the fence about whether to head to Austin next year. Afterward, I immediately booked my hotel for 2016. Hopefully I’ll see you there!

OSCON 2014

Another year, another OSCON. Now that I’m approaching caught up, here’s a quick recap of that busy week.

It was a busy OSCON for me this time around. I had two talks to give, only one of which I’d finished writing before I arrived. Oops. Ah, well. They both went well and were well-received and -reviewed, so I’m a happy camper. The slides and my webcam videos of both talks are available on Internet Archive:

Because my current job is so variable, my session attendance was equally variable. I didn’t really focus on any specific things, instead giving preference to talks by people I know and respect.

And, of course, there was the evening of Perl goodness: rjbs with a whole hurricane of lightning talks (in lieu of the State of the Onion, since Larry’s recovering from eye surgery), then a dozen or so individual lightning talks. As usual, rgeoffrey ran a tight ship and kept the talks moving smoothly.

Really, though, most of my time was spent sitting or standing around and talking to people. So many people. So, so many people. I’m not even going to attempt to list them all, but it was all time well-spent. I’m grateful for the opportunity to meet and befriend so many amazing and inspiring people.

One thing that did not happen that week was productivity. Beyond talking (both on stage and off), I accomplished little of substance. Not only does that make this subsequent week more difficult, it’s also an opportunity missed. I could have done some excellent collaboration that week. So when I read rjbs’s OSCON trip report I was intrigued by his idea to set up shop at a table & just get shit done next year. I’d back that play. I have plenty of projects which need love and attention, so having a personal OSCON Hackathon wouldn’t go amiss. Thanks for the idea, Rik!

Overall it was a great trip but an exhausting. I’m honored that I was once again invited to speak and overjoyed to have spent so much time with so many great friends, both old & new. You’ve filled my head with knowledge and ideas and wowed me with your accomplishments. Now I just need to figure out how best to apply all my newfound inspiration.