Concerns about the Community Data License Agreement (CDLA) initiative

xkcd on Standards: https://xkcd.com/927/

This week The Linux Foundation announced the new Community Data License Agreement licenses. I have not yet read the licenses themselves, as I’m still digging out from attending yet another amazing All Things Open, but even without knowing the contents of the licenses I have some questions and concerns.

Jim Zemlin, Executive Director of The Linux Foundation, is quoted in the CDLA press release as saying:

“An open data license is essential for the frictionless sharing of the data that powers both critical technologies and societal benefits…”

Well stated! Open licences for software, data, and other creative works are more important than ever for powering the innovation and invention that move us forward as an expanding civil society. They enable collaboration, without which we’d each be stuck in our own silos, continually reinventing the wheel.

What confuses me, however, is why The Linux Foundation decided to go its own direction rather than support and enhance the well established and understood Creative Commons licenses. There is no mention in the press release that other open data license options already exist, let alone whether they may have some shortcomings that the CDLA is intended to address. But those licenses do exist already, and their use is well documented and accepted by institutions worldwide. Does The Linux Foundation object to these licenses in some way that they created their own? Why fracture the data licensing space in this way?

In fact, Andy Updegrove, in a blog post welcoming CDLA into the world, stated that part of the motivation for its creation was specifically to avoid the license proliferation that plagued the early years of free and open source software and that was (and is) admirably curtailed by Open Source Initiative, its Open Source Definition, and its list of OSI-Approved licenses. By creating their own open data licenses instead of throwing their considerable weight behind the existing Creative Commons licenses, isn’t The Linux Foundation contributing to the license proliferation Updegrove says they’re trying to avoid?

That’s one concern I have with this announcement. The other is related to the source and warden of this new initiative.

The Linux Foundation is registered as a 501(c)(6) non-profit organisation. Colloquially known as a c6, these non-profit organisations are formed to promote shared business interests and are beholden to their members (typically businesses or business people themselves) to do just that. In the case of The Linux Foundation, it was originally formed to promote Linux in the business and enterprise space. It has done that brilliantly, and Linux is now the default operating system in servers, automotive, embedded devices, and just about anything else you can think of (save desktops, where it still has a long way to go).

The CDLA, however, claims it is not solely for businesses:

The CDLA licenses are designed to help governments, academic institutions, businesses and other organizations open up and share data, with the goal of creating communities that curate and share data openly.

While I wholeheartedly support the mission of helping governments, academic institutions, and other organisations open up and share data, I believe these institutions would be better served were the initiative brought by an organisation that is accountable to more than simply its members and their business interests. The Linux Foundation undoubtedly has the best intentions here. I do not question that. I do, however, question having the open data of governments and academic institutions being promoted by a group that by definition must dedicate itself to business interests. While undoubtedly The Linux Foundation would not intend to do so, as a c6 there is a risk that the business interests they are pledged to promote might influence the evolution and application of the CDLA licenses.

The optics of the CDLA initiative would be greatly improved were it instead managed by a 501(c)(3) non-profit. c3 non-profits have no accountability to business interests and instead operate solely for the public good (for, admittedly, very large values of both “public” and “good”). For instance, Creative Commons is a c3. Its mission and vision directly support the open sharing of data from government and academic institutions, as well as businesses, independent researchers, and any other data source:

Creative Commons develops, supports, and stewards legal and technical infrastructure that maximizes digital creativity, sharing, and innovation.

Our vision is nothing less than realizing the full potential of the Internet — universal access to research and education, full participation in culture — to drive a new era of development, growth, and productivity.

Again, I find myself confused why The Linux Foundation felt it necessary to proliferate open data licenses in this way. Hopefully more information and statements are forthcoming to explain their fractionalising move.

Entering the Free and Open Source emerging market

Originally published on opensource.com

In business speak, an “emerging market” is a market that is not yet well developed but on the rise and shows strong potential to be as robust as other developed markets. The Wikipedia definition focuses purely on countries, but this is a limited view of the meaning of “market.”

Whether a market is developed or emerging depends entirely on the product or service being offered and the receptiveness and awareness of a market to that product or service. For instance, Italy would not qualify as an emerging market by the Wikipedia definition. Yet, with an Internet penetration of only 58.5% of the country, it could be considered one for broadband Internet providers.

By this more inclusive definition, free and open source software (FOSS) is an emerging market for most of the corporate and business world. It’s a new land, abundant in resources and promise, and businesses are getting very excited about the possibilities. It’s also an entirely foreign culture, and many businesses are struggling to learn how to operate in this new land.

A new land

The place where business meets an emerging market is a liminal zone, which is space that is neither here (standard business practice) nor there (Wild West mentality), and where transformations are more likely to occur. In literature and mythology, all of the most exciting things occur in liminal zones. Operations in a liminal space, such as the meeting of an emerging market and a business, are not as constrained by a “business as usual” mentality; therefore, they are free to explore new solutions. The meeting of diverse approaches and philosophies can lead to incredible innovation in processes and products. With such potential, a growing number of businesses are looking to enter the FOSS emerging market, which is no surprise.

Entering a market is entering into a relationship, and like all relationships there is more than one perspective to consider. According to a study published in the MIT Sloan Management Review, this is where many organizations fail when attempting to enter emerging markets. Being very familiar with and confident in “how things are done,” organizations enter emerging markets with a business-as-usual attitude. They fail to do the necessary market research and don’t learn enough about the culture, the market needs, or even the communication norms and language. Unsurprisingly, their efforts lead to disappointment and a withdrawal from the market, usually to the benefit of local competitors.

This business-as-usual approach leads to expectation mismatch. Businesses expect that their usual go-to-market strategies will gain them entry, their usual processes will get things done, their usual messaging will gain them positive attention and brand recognition, and their usual language is appropriate for all communication. Some companies entering a FOSS community or project expect to mold them to their needs through force of numbers, either human or financial. This works about as well as you’d imagine. Companies expect Step 3: Profit will follow. Disappointed by unmet expectations, businesses decide that FOSS will never work for them. They withdraw from participation in FOSS and leave that emerging market to their competitors.

When businesses are unable to participate in FOSS, doors close for everyone. It deprives companies of the benefits of FOSS participation, including faster development and innovation, more efficient recruiting, word-of-mouth marketing, and lower total cost of ownership. The community or project becomes deprived of the benefits of corporate support, such as wages for maintainers, support for essential infrastructure, and sponsorship of events and participants.

How to step foot onto new land

As businesses set foot on the foreign land of FOSS participation, they should take care to treat it as they would any emerging market: with the respect and consideration due an unfamiliar culture. Businesses should tailor their entry to the market and not engage the autopilot to business as usual. Taking the time to pause, reflect, research, and listen can pay remarkable dividends and better ensure success. Part of this reflection should be confirming that the FOSS organization knows what it wants to get out of the relationship, and ensuring that this is a mutually beneficial arrangement. As with entering any new endeavor, you can reduce the time required to ramp up the team by hiring someone already familiar with this emerging market and its pitfalls.

While those of us on the management and business side of things learn how we enter the emerging market of FOSS, there’s no reason FOSS communities, projects, and supporters can’t do a little to help out our end. As with any relationship, meeting in the middle is the best way. For a successful entry into this emerging market, a business must learn the FOSS language, culture, and needs. The FOSS community can do its part to help a business do this, perhaps even by reaching out and offering to teach them. This may be one of the best approaches, because it also allows the FOSS community the opportunity to learn the language, culture, and needs of the business, making all communication more efficient and successful.

Most importantly, the FOSS community must try to be patient, non-judgmental, and empathetic when businesses inevitably stumble. Many people still retain an old-fashioned perception of emerging markets as savage or unsophisticated, although this is a view that has no place in technology or in business. The same can be said of business’ perceptions of FOSS. Many still see free and open source projects and practitioners as dogmatic, phlegmatic, and anarchic. Assisting businesses to enter the FOSS emerging market and picking them up should they fall will go a long way toward dispelling these misconceptions and we will all reap the benefits of broadening the scope of our collaborations.

Avoid failure when supporting free and open source communities

Originally published on opensource.com.

This is Part 3 in a series of articles three on community management best practices. Read Part 1, Practical business reasons to support open source communities, and Part 2, How your company can build and keep community trust.

Although supporting a community offers many benefits to an organization, to imply that there are no risks to the organization or community manager would be disingenuous. When handled poorly, engaging with a community can lead to major growing pains, raging headaches, and total meltdowns. In this article, I’ll discuss how to prevent the headaches before they happen.

If your organization decides to invest in and grow a community, not knowing why you are supporting a community and what results you expect are a huge problem. Humans—some more than others—are social creatures, so the appeal of being part of a community can be strong. However, that does not excuse your organization from responsible business practices. Undertaking any sort of large initiative without understanding the business reasons for doing so, or criteria and metrics for success, is irresponsible and not sustainable.

Defining ROI

Still, many organizations dive head first into community (and other) initiatives without having done basic due diligence from a business perspective. They fund the salaries of the community management team and sponsor community events without discussing assumptions, expectations, parameters, metrics, or anticipated ROI from the endeavor. Down the road, this inevitably leads to awkward conversations. And some of these conversations negatively impact the community, which can lead to serious blow-back and negative PR for the organization.

Another risk organizations face when initiating a community support program is mistaking the community for a market or for customers. Although community members may also fit these roles, and traditional marketing and sales outreach techniques can be helpful at times, treating the community like anything other than a community can lead to resentment and ill-will from its members. Remember: A community is a self-organized and self-identified collection of people. Identification is a powerful thing, and treating someone contrary to their selected identification is arrogant and disrespectful. When an organization begins to think of the community as merely a well-qualified market or as sales leads, it has lost connection with the community and risks losing members and public negative feedback.

Community value

Organizations that do not think through business aspects of their community support programs risk devaluing the community they support. Without considering the business case for supporting a community, the organization can fall into thinking that any community will do, and that this community is expendable or hot-swappable for another that the organization can simply support or build in parallel. Again, this line of thinking ignores community self-organization and identification. It dehumanizes the community members, treating them as interchangeable cogs turning in a machine cranked by the organization. This dehumanization creates a blind spot in the organization such that they are surprised when the community exercises its agency and independence, often with unfortunate results for the organization.

Organizations that decide to support a community and then, through neglect, allow the community to fall into disrepair are also at risk. Communities will self-manage; there is no requirement for an organization to swoop in and offer its support on that front. But a self-managing community is not always a healthy community. Through neglect, indifference, or political skulduggery a community can become a negative space that is unwelcoming to the new, the reasonable, the empathetic.

An organization that reneges on its promise to help manage and lead a community cannot walk away from the reputation it earns by being associated with a negative and toxic community environment. This is, of course, a worst-case scenario. More often, a community left in neglect withers and dies silently. But sometimes thriving and toxic weeds overrun it, and ignoring this possibility is a mistake that a supporting organization makes at its own peril.

Then there is the problem of expectations mismatch. The organization cannot simply decide to support a community, go stomping in there waving money and touting their principles, and then expect to be embraced as a conquering hero. Entering a community, as I mentioned in Part 2, takes time and deliberate effort. A large part of that effort is communicating why the organization has decided to become a part of the community, what they hope to gain, what the community will gain, and how the organization intends to operate both within and outside the community.

Communication is key. Both sides must openly outline expectations, otherwise they risk an expectations mismatch, which can sour the community to future support from the organization. If the organization supports and listens to a skillful community manager who understands the community and its members, the chance of an expectation mismatch goes down. The communication pipeline provided by the community manager ensures that all sides understand what is going on, when, why, and how everyone can contribute.

Enter the community manager

I’ve discussed the benefits and risks to organizations supporting communities, but there’s another piece of the equation that is often overlooked: risks to the community managers themselves.

Community manager (or a variant, such as developer relations) is a relatively new job title in the tech industry. As organizations began to recognize benefits of supporting a community, they also began to see the need to have one or more employees guiding, growing, and communicating with that community. But problems with this role can start early on, when organizations aren’t clear on expectations and requirements for measuring the community manager’s success.

Community managers are in curious and occasionally awkward positions. To succeed at their jobs, they must participate in their communities at a level that can appear to be disloyal to an employer and in favor of the community. In fact, a successful community manager plays the role of diplomat and translator between organization and community, representing the organization’s interests within the community, while transmitting the feedback and concerns of the community back to the organization. The community manager must understand the perspectives and motivations of each side and work to balance and achieve goals to benefit both.

This is a difficult task in the best of situations, but becomes particularly challenging when the organization misunderstands the diplomatic role of the community manager, and instead expects them to enforce organizational edicts without regard to effects on the community. This can be perceived as disloyalty to the organization rather than what it is: the community manager working to protect the reputation of the organization.

Community manager ROI

Community managers also have the challenge of proving their value to their organizations. The metrics required for such validation often are difficult to track, nebulous, or both. Proving the ROI of a community support program is hard enough; proving the impact of an individual community manager on that ROI is even more difficult. For the sake of community managers and of the community program, that organizations define metrics and criteria for success before beginning the undertaking is vital.

Community managers who are not armed with metrics and organizational expectations are unable to show the value they bring to an organization, and they become low-hanging fruit when budgets are cut, and they can be cut out of the picture. Often organizations that choose this option are those that failed to outline their motivations and expectations for supporting a community. And, having not thought things through from the start, these organizations rarely have considered the repercussions that losing a community manager can have on the community and how it views the organization.

Other risks to community managers are more personal in nature. For instance, embedding oneself within a single community can lead to difficult career mobility. Becoming a trusted member of a community takes a great deal of time, energy, and emotional investment, and although the relationships built and interpersonal skills learned are valuable and transferable, a community manager cannot simply jump from one community to another as easily as a programmer can move from one project to another. When an organization decides not to continue supporting a community, or if the community manager is no longer satisfied with their role or organization, finding a new position can be difficult.

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.

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