Jump-start your career with open source skills

Not Another Jump Shot by pinkcotton on Flickr, CC BY-NC-ND Although attending college is not required for success in software development, college programs can provide a great deal of useful information in a relatively short period of time. More importantly, they are designed to cover all necessary concepts without the knowledge holes some self-taught practitioners suffer. College programs also often include theory and history, which can form the foundation for professional exploration and decision-making.

Yet college graduates entering the workforce often find their coursework has emphasized theory over the practice, technologies, and trends required for success on the job. The reason? Curricula take time to develop, so institutions of higher education often teach technologies and practices that are at the tail end of current usage.

Internships

Fortunately, there are ways to learn and develop the knowledge and skills you need to land a job and succeed in today’s workplace. One approach is the internship. Many students spend mid-term breaks interning with organizations. Internships are an effective way to gain exposure to different technologies and techniques than those taught in school. An added bonus: you’ll get paid to do so (do not accept an unpaid internship; your time is valuable).

Of course, competition for the best internships can be stiff, and it might be difficult to find an internship in the area or industry that most interests you. Also, don’t expect to intern on your schedule; you’ll likely spend the holiday working rather than relaxing and spending time with family and friends. Consider it the trade-off for gaining experience that will give you a leg up when you start your career.

Contributing to open source projects

Another way to gain extra knowledge is to participate in, and contribute to, free and open source software (aka FOSS). There are millions of FOSS projects that offer a nearly infinite variety of learning opportunities. It’s a superb way to learn critical skills you may not get in school, such as QA, version control, writing tests, using continuous integration and development, writing documentation, and designing user interfaces. You can participate in FOSS on your own schedule, any time of the year. FOSS participation offers the opportunity to learn from, and be mentored by, some of the best and the brightest in the industry. It also allows you to build a portfolio of publicly available work, which will impress prospective employers much more than standard coursework.

Finding an internship can be as easy as visiting your college’s career and employment office. But how do you find a FOSS project to contribute to?

Finding a project

Several online services are available to help people contribute to free and open source software. Some provide tips for contributing, while others act as matchmakers, pairing people with projects that need help. First Timers Only, in addition to being a movement requesting and helping project maintainers label bugs as #first-timers-only, presents new contributors with helpful links and tips to get started. GitHub Explore and CodeTriage both provide pointers to interesting projects that are looking for new contributors. During the Christmas holiday season, 24 Pull Requests is a great way to find projects that need help.

Your search for FOSS projects needn’t be limited to online. Most urban areas and many smaller communities play host to different events where you can learn and contribute in person. Many groups post their events, conferences, and hackathons on Meetup.com or even on Facebook, but don’t forget that your local public or college library is a valuable resource to learn about events in your community. If you can’t find a group, start one! The library is also a great place to post meetings and bring together people who wish to explore open source contributions.

New contributor-friendly projects

Some projects are known to be particularly friendly and helpful to new contributors. What follows is far from a complete list:

Finally, keep in mind that free and open source software needs programmers, but it also needs designers, writers, marketers, and more! Developing and supporting FOSS is truly a multidisciplinary undertaking. Whatever you do, and wherever you wish to take your career, free and open source software can help you learn what you need to be successful and competitive in the job market.

Originally posted at opensource.com

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.

Google, can we talk?

The following is an edited screenshot of my Google Account profile:

My Google account profile

Google, my dear, do you see all of those email addresses listed there? Each and every one of them was not only added to my profile by me, I also took the time to verify with you that each of them is really, honestly, and truly mine and that I wanted them associated with my Google account. You know they’re associated with my account. I know they’re associated with my account. We are in blessed agreement on this point.

Google, my love, you are amazing. You can take my search terms and return a billion results plus relevant advertisements in a blink of an eye. Truly, you are the pinnacle of data association and retrieval.

Google, my pet, so why is it when someone sends me a Google Docs invitation–to one of those emails which we agree are associated with my Google account, by the way–why is it you won’t allow me to access the doc despite my being logged into my Google account? Why are you incapable of performing the (as appears from your users’ perspective) relatively simple lookup to confirm that the address to which the invite was sent is in fact associated with the account which is logged in? Why can you not also do that in the blink of an eye?

Google, my beloved, you have had a very long time to fix this very irritating and, to be honest, quite large usability bug. What’s the hold up? Frankly, people are saying some rather unsavoury things about you. Things like, “Google is an advertising company, not a product company, and therefore it doesn’t care about its users or usability.” Is that true, Google?

Because Google, my sweet, it certainly seems that way from where I’m sitting.

Thanks for the talk. I hope it helped you, because you’re certainly not helping me right now.

Don’t hire team members like they’re consultants


There’s a problem I keep seeing when helping my clients, providing career coaching to job seekers, and participating in interviews myself: Tech companies consistently take the wrong approach when hiring for new team members.

Let’s set up a couple of use cases…

Comparing apples…

Your product has an urgent technical need. Maybe you need to integrate with a new system which uses unfamiliar protocols. Perhaps a creaky old legacy system needs shoring up or replacement. Or maybe you’ve acquired another company and need to convert their billing system over to use your tooling. Whatever it is, it has to happen and it has to happen now.

What you need is a consultant: Someone who’s intimately familiar with the technology causing your immediate problems. Someone who can dive right in, change some code, then get right out. Someone who’ll take a month or six, make the technical pain go away, and then leave for the next gig.

That’s use case number one.

…to oranges.

Now let’s say your company has an open req. Maybe you’re replacing someone who’s moved on. Maybe you’re expanding the team as the company grows and scales. Or perhaps you’re moving into a whole new product or market area. Whatever your reason for hiring, it needs to happen and it needs to be done right rather than right now.

What you need is a team member. Someone who’s able to collaborate, communicate, innovate, and deliver. Someone who’ll commit to the team and the company, who’s in it for the long haul. Most importantly, you need someone who’s able to learn and adapt along with the company’s needs.

That’s use case number two.

Two use cases, one hiring approach

When the differences between these two hiring use cases are so stark, and when the costs of hiring/firing/replacing a poor choice are so high, why does nearly every tech company hire team members as though they’re hiring a consultant? Job postings focus on the current tooling and products rather than factor in future plans. Interviews focus on the immediate technical knowledge and abilities of candidates, rather than on the candidates’ capabilities for learning and adapting. Companies hire the wrong people for the wrong reasons, then are surprised to find they can’t scale or adapt to meet strategic goals.

There are several reasons why this continues to happen. For starters, very few tech companies are equipped with people who have experience with a proper hiring process. Rather than approaching the process like the complex project that it is and gathering requirements before taking action, hiring managers do the best they can with the little information they have. When faced with an unfamiliar situation, we fall back on what we know. In the case of hiring, this typically means copying and pasting a job posting rather than considering the strategic requirements for a role.

It also means interviewing people for skills they have now rather than for the skills they’ll need in order to move the team and company toward their goals. If you’ve never been trained to think strategically about hiring, you’re unlikely to ask strategic interview questions. Again, we fall back on what we know, and what we know is our own tech stack and our own immediate problems. We ask questions about the things foremost in our minds rather than considering the long term needs of the group. This makes it much easier for untrained interviewers to determine a thumbs-up/thumbs-down on a candidate. Do they know our tech? No? Then they’re not a good fit. The question of whether they can learn your tech never even occurs to us. We’re focused on the now rather than the future.

This short-sighted interview strategy is employed in nearly every tech team regardless of industry and makes a expensive trade: the team’s long-term success for the immediate comfort of the interview committee. Otherwise exceptional candidates are rejected in favour of mediocre ones who have more familiarity with the technologies used but less ability to communicate, learn, and adapt. They interview for consultants rather than for team members and the long-term health of the team suffers.

We can do better

It won’t be easy to do, but this is a fixable problem. You can start it in your team today.

First, give more thought to your job postings. Don’t simply copy and paste from the last time you were hiring for this role. Consider not only what the person hired will do in their first month but also how you’ll need them to adapt and make a difference in their first year and beyond. Craft a posting to reflect the long-term needs of the team, not simply seeking someone to scratch an immediate itch you’re feeling.

Next, take the time to seek out and provide training for those performing the interviews. You probably wouldn’t let your brand new intern make changes to a vital production system without a lot of training, yet we regularly have untrained people perform interviews. As with many other elements of software development, interviewing is a skill and must be learned and practiced. There are people who can provide this training, or you can take the time to learn interviewing skills yourself then pass them on to the rest of the team. Experiential interviewing, bias limitation, and strategic thinking are just a few of the skills required for effective interviewing.

Naturally there are other steps for improving the tech hiring process, but these two would be a very good start. Hiring well requires both intention and attention. Don’t throw away the precious opportunity to build something great by phoning it in and treating a long-term investment in the team like a short term investment in a consultant.

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.

Advice for new speakers

After my speaker training workshop at /dev/world/2017 last week, one of the attendees approached me asking whether they could contact me with some more questions. Recently they sent their questions along and it turns out they have a lot of the same questions as many new speakers. After seeing this, I asked whether I could share both the questions and answers here so everyone could benefit. Thanks to the original asker for permission to do so.

The questions:

The main problems that I have are:

  1. Finding topic to present. Whatever idea that I have in mind, it appears that most people know about it already. Any suggestions or tips on how or where to find good topic to present?

  2. Also, I often question myself. Am I the best person to present a particular topic? What if one of the audiences is an expert in this area. I make a fool of myself. I know this mindset is wrong. What’s your personal tips to get over this?

  3. Finding the right event/conference to start. Any suggestion on how to find event/conference that is not too demanding for a starter like me? I don’t know whether an event like /dev/world is too big for a starter or not.

Let’s take these one at a time. What follows is pretty long since it seems I have a lot of thoughts about conference speaking (I have do a two hour training about it, after all).

Finding topic to present. Whatever idea that I have in mind, it appears that most people know about it already. Any suggestions or tips on how or where to find good topic to present?

No matter the topic, I can almost guarantee that most people do not know about it. However, most people at the conference you are targeting might. The topic you present must provide value to the audience, therefore you should either select a topic to match the conference audience (if you already have a conference in mind) or a conference audience to match the topic (if you already know what you’d like to present about). If there’s a mismatch between topic and conference, then your talk will not be selected for the program. This doesn’t mean that it’s not a good topic, simply that it’s not a good fit for that audience.

So, where are you starting? Do you have an idea and need a conference where it would be a decent fit? Or do you have a conference and need to come up with a topic which will work for it?

For the former (you have an idea already), there are several approaches you can take to locate appropriate conferences:

  1. Check conference aggregators like Lanyrd or the opensource.com event calendar. When you find some conferences which look like they might be good for your topic, check their past schedules or CFP texts to confirm your topic will be a decent fit for their audience.
  2. Search YouTube for other conference talks similar to your idea. Which conferences accepted those talks? Chances are good they’ll be interested in other talks along the same lines.
  3. Don’t present at a conference at all. Have a look for meetups or user groups in your geographic area, and offer to present your talk at one (or more!) of them. Meetups are always looking for people to present, so you’re likely to get someone to say yes to your talk this way. Not only can this allow you to present your material more quickly (since you won’t have to wait for a conference), it also is a great way to workshop and polish your talk before you present it in a larger venue like a conference.

If you already have a conference in mind and just need a topic to propose to it:

  1. Please read and adhere to the conference CFP directions. The call for proposals will almost always list the types of subject matter in which the conference is interested. If that list doesn’t include something on which you can present (say it’s a Windows conference but you only know Mac or Linux), then do not propose something completely unrelated. This wastes the time of the proposal reviewers and makes you look like you can’t follow directions.
  2. Have a look at the topics of past talks at that event. Can you present on anything like those topics? Perhaps someone spoke about a certain library once, a library which you recently used to solve a complicated problem. Your story of the problem and how you solved it would likely make a great talk for that conference.
  3. Look at the past presenters at that event. Are there any which you recognise? If so, have a look at some of the other talks those people have given at other events. This could provide the inspiration you need for coming up with your own talk idea.

But what if you don’t have a talk idea and you don’t have a conference in mind, you simply have a burning desire to start presenting tech talks? In that case, it’s often easiest to start with finding an idea and then find meetups/conferences to match it. So, how do you come up with an idea when you don’t have a conference in mind?

Look at what you’ve worked on (in the office or for hobby projects) in the past year. What challenges have you faced? What challenges have you overcome? What challenges overcame you? Have you discovered a new tool which made a great difference to your project? Did you try other tools and learn that they weren’t all they were cracked up to be? These are just a few of the questions which can lead you to some really great talk ideas.

When answering these questions, just grab a cup of tea, sit down for an hour or so, and brainstorm at a whiteboard or notebook or whatever works best for you. Give yourself permission to write anything which comes to mind. There are no bad ideas at this point; all ideas are equally good when they’re first born. After you’ve emptied your brain, review the list you’ve generated. There will undoubtedly be a few really interesting talk ideas in there.

Also, I often question myself. Am I the best person to present a particular topic? What if one of the audiences is an expert in this area. I make a fool of myself. I know this mindset is wrong. What’s your personal tips to get over this?

Do a search for a topic. Look at the people who present about it. Are they all the world’s foremost experts? No. Well, OK, maybe some of them are. But most of them are people just like you, people who have knowledge and a story to tell. The only difference between them and you is that they’re already telling that story and you’re just getting started.

The best person to present on a particular topic is the person who is willing to present on it and who knows enough to do so. That’s all the expertise you need. You do not have to be intimately familiar with every facet of the technology or topic. You do not have to be a renowned expert. You simply have to know enough to present the topic effectively and answer questions from the audience afterward.

There is no “must be an expert” requirement for presenting at technical conferences, and anyone who tells you differently is both elitist and wrong. The knowledge requirements for presenting at a tech conference are simple:

  1. Be well versed in your particular topic.
  2. Know how to admit you don’t have all the answers.

That’s it.

There are some conferences and events which prefer presenters be a core contributor or other key player in the technology or topic. This is perfectly fine…if the topic in question is how to contribute or be a key player. If the topic is just about anything else, then skilled users have valuable viewpoints and experiences to share with the audience members.

This “contributor” versus “user” bias is pure elitism and sets up an unwelcome caste system in the already fractured tech culture. It also perpetuates the dreadful diversity in conference presenters by setting a very high bar for new speakers to enter the fold. If you come across a conference with this sort of speaker selection bias, I encourage you to propose your talk elsewhere. Don’t be a part of the problem; find a more welcoming and supportive speaking environment.

Aside from avoiding unsupportive conferences, I encourage you to propose talks even if you don’t feel like you’re not an expert. Allow the programme committees to make that decision; don’t make it for them by not even trying.

Finding the right event/conference to start. Any suggestion on how to find event/conference that is not too demanding for a starter like me? I don’t know whether an event like /dev/world is too big for a starter or not.

I covered most of this above in the answer to the first question, but you asked three questions so you’re going to get three answers. 😉

There’s not much difference between presenting to a room of five or to a room of five hundred. I mean, there’s some difference, but practically speaking you’re just…well…speaking. You still need to come up with an idea, research your audience, write the material, practice your performance. Most of the difference, really, comes in the content. You’re less likely to have interactive material for a large audience than for a small. Aside from that: the mechanics of the thing are the same.

The real difference is in your own head. Where will you be most comfortable starting out? For many, the answer is to start at a local meetup and then level up onto a conference stage, expecting that this will move them from a small audience to a larger. But what a lot of people don’t realise is that for most conferences you won’t have a large audience, anyway.

Take /dev/world/2017 for an example. While some talks (the workshops and keynotes) had audiences over a hundred, the majority of them were between thirty and fifty. That’s much larger than you’ll find at most conferences and is great audience turnout (which is no surprise, as the /dev/world team does really good work on their events). While I’ve presented to hundreds at a time before, it’s much more likely that my audience will be around ten or twenty people, even at the largest events where I present.

Compare that to a meetup, where you’ll be presenting to…how many? It will vary, but ten or twenty people would be a decent turn out for most of the meetups I’ve seen. So you could present to ten or twenty people at a meetup, or you could present to ten or twenty people at a conference. Or you could present to fifty at either. Or a hundred. It’s often difficult to estimate how large of an audience you’ll have.

So if the mechanics of presenting are the same, and the size of the audience is impossible to estimate, how do you choose where to start?

Start with whatever makes you feel most comfortable. If that’s a lightning talk at a meetup, then it’s a lightning talk at a meetup. If it’s a fifty minute talk at a large event, then it’s a fifty minute talk at a large event. There is no right or wrong answer.

But, to answer the final part of your question: Yes, I think that /dev/world would be a great place to start, if you’re willing to wait until next August. As I already mentioned, the organisers do a great job on the event. They also care a great deal about supporting new speakers, to the point that they’ve brought me from the US two years in a row to provide speaker training. Each year I’ve seen multiple first-time presenters take the stage and deliver great content to engaged and appreciative audiences. And keep in mind: /dev/world is run by a student organisation and encourages the participation of students and professionals alike. This focus on education adds to the welcoming environment for new speakers.

Hopefully I’ve answered your questions, and provided guidance for all potential new speakers who might happen across this post. Don’t forget, other resources are available:

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.

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.

Google’s disappointing response to the “manifesto”

I’ve been sitting on this for a day, and I really do have better things to do than to scold strangers on the internet, but after sleeping on it I find I need to get this out…

Yesterday Google released its official response to a recent internally-released-but-now-leaked manifesto on gender and Google’s support of its equality. The official reply does Google, its brand, and its reputation no favours.

For starters, this so called “manifesto” is the worst sort of faux-intellectual, self-delusional, self-congratulating, adolescent bullshit. Full stop. This man obviously thinks himself very clever and knowledgable, when evidence shows that he is anything but.

But I’m not here to talk about this programmer today. The last thing this creature needs is more attention. I’m here to talk about how Google is making a very dire business mistake.

The response states:

Part of building an open, inclusive environment means fostering a culture in which those with alternative views, including different political views, feel safe sharing their opinions.

In principle there is nothing wrong with this statement, but the reality is that while people should feel safe sharing their opinions, they also must be trained that not all opinions or topics are appropriate in all environments or conditions.

In this case, the unnamed software developer has expressed an opinion which is counter to Google’s own “strong stand on this issue.” There is nothing wrong with that. He is welcome to his own opinion, however catastrophically wrong, puerile, shortsighted, and unadulteratedly stupid it may be.

However, this opinion was expressed in such a way that it has publicly called Google’s commitment to gender equality into question. If that’s not enough of a negative effect for them, then how about the bottom line? The furor over this simplistic armchair philosophy of a screed has seriously injured Google’s multi-billion dollar brand and wasted countless hours of company time.

How many millions of dollars of damage has this man’s public mental masturbatory male power fantasy done already? How many millions more will it take to heal the wound he has caused?

There is safety to express one’s views, and then there is safety to torpedo a company’s reputation. There is free speech, and then there are the ramifications for one’s speech. This software developer must learn that while he has the former, he also has the latter.

For the sake of its brand and its reputation, Google must make a decisive statement now. It must do better than the flacid response it made yesterday. It must show that actions which cause harm to the company and its initiatives are not welcome and will be met with a commensurate reaction. Or, more colloquially: Ya don’t shit where ya eat, dude.

Fire this man & make a statement to that effect. He’s a fool with poor judgement and he’s an albatross hung on Google culture and Google reputation.