Every organization, community, and family has difficult people in them. Some get overly agitated, some are not constructive in their criticism, some rub other people up the wrong way, some always commit but never deliver, and other traits.
In my new video I share some details for how to manage these types of personalities. I share some golden rules for handling them, how to analyze the situation well, and a method for building a resolution and solving problems.
Here it is:
Can’t see it? Watch it here.
A few weeks ago I ran the ninth annual Community Leadership Summit in Portland, Oregon. As usual, O’Reilly provided the venue space and AV for us (as it happens the weekend before OSCON), and we had a fantastic line-up of sponsors, including:
Many thanks to all our fantastic sponsors!
The event was fantastic. We had over 200 great attendees (from all manner of backgrounds, disciplines, and experience), 8 keynotes, 40+ discussion sessions, and a raft of fantastic hallway discussions, social events, and more. Thanks also to Todd Lewis, Aaron Griswold, Van Riper, Catharine Lipton, and others who helped make this a success.
While CLS is in it’s ninth year, this year felt even more energized than usual. There were some deep, complex discussions getting to the heart of how people collaborate, and these conversations covered a wide range of topics.
Here are some photos from the event (thanks to Jim Grizanzio for taking these, and see the full album):
See you next year, everyone!
Last week I ran the Community Leadership Summit in Portland, Oregon, and also attended the OSCON summit there. It was a fantastic week and I will be following up with more details about CLS soon.
While there, my old friend (and editor of The Art of Community), Andy Oram, asked if he could interview me about how community leadership has evolved over the years. We had an interesting discussion, touching on how this work has changed, how the job descriptions and roles have adjusted, how companies fit it into their organizations, and more.
You can watch it here:
Can’t see the video? See it here.
Recently I gave a keynote at DevXCon in San Francisco. So, what better place to deliver a presentation that is entirely non-technical and non-specific to developer relations?
“You are bonkers, Bacon”, I hear you say.
Well, hold your horses. Effective leadership, how we identify quality leaders, and how we foster great leadership at scale is critical to all communities. As such, I took a crack at this topic in my keynote. Fortunately, it seemed well-received by the folks there.
Now it is your turn to decide. Here is the video:
Can’t see the video? Click here.
I would love to hear your ideas about what great leadership consists of and how you have approached this. Share your thoughts in the comments!
One thing I see clients reach for the Pepto about over and over again is how to manage work effectively. They often struggle to (a) gather and communicate requirements (and not a Christmas list), (b) understand these needs and set expectations, and (c) manage how this work is actually delivered. When this isn’t smooth, it is a royal pain in the behind.
As part of my Open Org series, here is my new video covers precisely this:
Can’t see it? See it here.
Don’t forget to see my first part of the series too, which covered how to communicate effectively across different parts of an organization. This is really important, particularly if you are working with executive teams. Check it out:
Can’t see it? See it here.
Feedback is always welcome!
Recently the news broke that Microsoft are acquiring GitHub. Effusive opinions flowed from all directions: some saw the acquisition as a sensible fit for Microsoft to better support developers, and some saw it as a tyrant getting their grubby fingers on open source’s ecosystem.
I am thrilled for Microsoft and GitHub for many reasons, and there will be a bright future ahead because of it, but I have been thinking more about the reaction some of the critics have had to this, and why.
I find it fascinating that there still seems to be a deep-seated discomfort in some about Microsoft and their involvement in open source. I understand that this is for historical reasons, and many moons ago Microsoft were definitely on the offensive against open source. I too was critical of Microsoft and their approach back in those days. I may have even said ‘M$’ instead of ‘MS’ (ugh.)
Things have changed though. Satya Nadella, their CEO, has had a profound impact on the company: they are a significant investor and participant in open source across a multitude of open source projects, they hire many open source developers, run their own open source projects (e.g. VSCode), and actively sponsor and support many open source conferences, events, and initiatives. I know many people who work at Microsoft and they love the company and their work there. These are not microserfs: they are people like you and me.
Things have changed, and I have literally never drunk Kool-aid; this or any other type. Are they perfect? No, but they don’t claim to be. But is the Microsoft of today a radically different company to the Microsoft of the late nineties. No doubt.
Still though, this cynicism exists in some. Some see them as a trojan horse and ask if we can really trust them?
A little while ago I had a discussion with someone who was grumbling about Microsoft. After poking around his opinion, what shook out was that his real issue was not with Microsoft’s open source work (he was supportive of this), but it was with the fact that they still produce proprietary software and use software patents in departments such as Windows and Office.
Put bluntly, he believed Microsoft are ethically unfit as a company because of these reasons, and these reasons were significant enough to diminish their open source work almost entirely.
Now, I am always fascinated when people use the word “ethics” in a debate. Often it smacks of holier-than-thou hyperbole as opposed to an objective assessment of what is actually right and wrong. Also, it seems that when some bring up “ethics” the discussion takes a nosedive and those involved become increasingly uninterested in other opinions (as I am sure we will see beautifully illustrated in the comments on this post 😉 )
In this case though, I think ethics explains a lot about the variance of views on this and why we should seek to understand those who differ with us. Let me explain why.
Many of the critics of proprietary software are people who believe that it is ethically unsound. They believe that the production and release of proprietary software is a fundamentally pernicious act; that it is harmful to society and the individuals within it.
I have spent my entire career, the last 20 years, working in the open source world. I have run a number of open source communities, some large, some small. I am a live and let live kind of guy and I have financially supported organizations I don’t 100% agree with but who I think do interesting work. This includes the Free Software Foundation, Software Freedom Conservancy, and EFF, I have a close relationship with the Linux Foundation, and have worked with a number of companies on all sides of the field. Without wishing to sound like an egotistical clod, I believe I have earned my open source stripes.
Here’s the thing though, and some of you won’t like this: I don’t believe proprietary software is unethical. Far from it.
Clearly murder, rape, human trafficking, child abuse, and other despicable acts are unethical, but I also consider dishonesty, knowingly lying, taking advantage of people, and other similar indiscretions are unethical. I am not an expert in ethics and I don’t claim to be a perfectly ethical person, but by my reasoning unethical acts are a power imbalance that is forced on people without their consent.
Within my ethical code, software doesn’t get a look in. Not even close.
I don’t see proprietary software as a power imbalance. Sure, there are very dominant companies with proprietary platforms that people need to use (such as at your employer), and there are companies who have monopolies and tremendous power imbalances in the market. My ethical objection there though is with the market, not with the production of closed source software.
Now, before some of you combust. Let me be clear on this: I am deeply passionate about open source and free software and I do believe that proprietary software is sub-optimal in many situations. Heck, at least 60% of my clients are companies Ia m working with to build and deliver open source workflow.
In many situations, open source provides a much better model for collaboration, growth, security, community development, and other elements. Open source provides an incredible environment for people to shine: our broader open source ecosystem is littered with examples of under-represented groups doing great work and building fantastic careers and reputations. Open source and free software is one of the most profound technological revolutions, and it will generate great value and goodwill for many years to come.
Here lies the rub though: when I look at a company that ships proprietary products, I don’t see an unethical company, I see a company that has chosen a different model. I don’t believe the people working there are evil, that they are doing harm, and that they have mendacious intent. Is their model of building software sub-optimal? Probably, but it needs further judgement: open source clearly works in some areas (e.g. infrastructure software), but has struggled to catch on commercially in other areas (e.g. consumer software).
Put simply, open source does not guarantee success and proprietary software does not guarantee evil.
Throughout the course of my career I have always tried to understand other people’s views and build relationships even if we see things differently.
As an example, earlier I mentioned I have financially supported the Free Software Foundation and Software Freedom Conservancy. Over the years I have had my disagreements with both RMS and Bradley Kuhn, largely based on this different perspective to the ethics of software, but I respect that they come from a different position. I don’t believe they are “wrong” in their views. I believe the position they come from is different to mine. Let a thousand roses bloom: produce an ecosystem in which everyone can play a role and the best ideas will generally play out.
What is critical to me is taking a decent approach to this.
We don’t get anywhere by labelling those who work at or run companies with proprietary products as evil and as part of a shadowy cabal. We also don’t get anywhere by labelling those who do consider free software to be a part of their ethical code as “libtards” or something similarly derogatory. We need to learn more about other people’s views rather than purely focusing on out-arguing people. Sure, have fun with other people’s views, poke fun at them, but it should all be within the spirit of productive discourse.
Either way, no matter where you draw your line, or whatever your view is on the politique du jour, open source, community development, and open innovation is changing the world. We are succeeding, but we can do even greater work if we build bridges, not firebomb them. Be nice, people.
I realized I haven’t been putting many videos online recently. As such, I have started recording some instructional and coaching videos that I am putting online that I hope are useful to you folks.
To get started, I wanted to touch on the topic of handling failure and poor decisions in a way that helps to identify pragmatic outcomes and lead towards better outcomes. This video introduces the issue, delves into how to unpick and understand the components of failure, and some practical recommendations for concrete next steps after this assessment.
Here is the video:
Can’t see it? Click here.
Back in February I announced the Call For Papers for the Open Collaboration Conference was open. For those of you in the dark, last year I ran the Open Community Conference as part of the Linux Foundation’s Open Source Summit events in North America and Europe. The events were a great success, but this year we decided to change the name. From the original post:
As the event has evolved, I have wanted it to incorporate as many elements focused on people collaborating together. While one component of this is certainly people building communities, other elements such as governance, remote working, innersource, cultural development, and more fit under the banner of “collaboration”, but don’t necessarily fit under the traditional banner of “community”. As such, we decided to change the name of the conference to the Open Collaboration Conference. I am confident this will then provide both a home to the community strategy and tactics content, as well as these other related areas. This way the entire event services as a comprehensive capsule for collaboration in technology.
I am really excited about this year’s events. They are taking place:
- North America in Vancouver from 29th – 31st August 2018
- Europe in Edinburgh from 22nd – 24th October 2018
Last year there was a wealth of tremendous material and truly talented speakers, and I am looking forward to even more focused, valuable, and pragmatic content.
North America Call For Papers Closing Soon
…this neatly leads to the point.
The Call For Papers for the Vancouver event closing on 29th April 2018. So, be sure to go and get your papers in right away.
Also, don’t forget that the European event has the CFP close on the 1st July 2018. Go and submit your papers there too!
For both events I am really looking for a diverse set of content that offers genuine pragmatic value. Example topics include:
- Open Source Metrics
- Incentivization and Engagement
- Software Development Methodologies and Platforms
- Building Internal Innersource Communities
- Remote Team Management and Methods
- Bug/Issue Management and Triage
- Communication Platforms and Methods
- Open Source Governance and Models
- Mentoring and Training
- Event Strategy
- Content Management and Social Media
- DevOps Culture
- Community Management
- Advocacy and Evangelism
- Government and Compliance
Also, here’s a pro tip for helping to get your papers picked.
Many people who submit papers to conferences send in very generic “future of open source” style topics. For the Open Collaboration Conference I am eager to have a few of these, but I am particularly interested in seeing deep dives into specific areas, technologies and approaches. Your submission will be especially well received if it offers pragmatic approaches and value that the audience can immediately take away and apply in their own world. So, consider how you package up your recommendations and best practice and I look forward to seeing you submissions and seeing you there!
I have noticed an interesting pattern when some new projects and initiatives get started: they have an excessive application of governance, in many cases to deliver an impression of “completeness” or project independence. I want to share a few words on how to avoid this over-complexity.
I understand why this happens. Generally, successful collaborative communities strive to be very objective environments, with process, workflow, and governance clearly documented as a means to ensure anyone and everyone can contribute. The governance piece plays a key role in affirming objective leadership and avoiding conflicts of interest.
These are valiant goals, but there needs to be a careful balance of this process and governance, where it is blended with a robust focus on simplicity and efficiency. I have seen many projects unwittingly sacrifice agility and the plain joy of participating with an overly bureaucratic machine that a few governance nerds obsess over.
There are countless examples (that shall remain anonymous here), such as a new advocacy group of around 10 people who had 2 boards to govern them (everyone was on a board) and had excessively long meetings. There was the concensus-based board with 18 members that could never make decisions. There was the community that required excessive commitments from their members to overly bureaucratic governance mantra handed down from high. In all of these cases those communities were worsened, not strengthened by governance.
The solution here is start small and simple, and then observe and iterate.
Just like how a chef applies salt to a dish, you should apply the smallest amount possible and adjust to taste. Start by putting in place the thinnest layer of governance possible to accomplish your goals.
To start with this we need to understand what our governance goals actually are. Again, simplicity is key here. I generally recommend you strive to build an environment in which formal governance is kept out of the day to day of participation in the community and instead focused on the rules and policies that underlay the project. Don’t bottleneck your community by requiring governance approval on decisions unless absolutely necessary (e.g. community-wide policy is a great governance-target, but not pull request approvals). Effective governance is as much about knowing where governance boards should steer clear of as well as where they should focus their attention.
Governance can of course be as long as a piece of string. The simplest start in many cases is no governance at all. See how the project runs and if there is even a requirement for a governance function. In many, many cases you simply don’t need any governance: just a communicative set of community participants who can make decisions collaboratively.
If there is a need for something more expansive, I recommend you start with a simple board of 3 – 5 people whose charter is focused on general community matters (e.g. handing sponsor funds, how the community is moderated, publishing policy etc). For technology communities, the board would not have any technical authority: that is for the developers to decide (this avoids impacts on engineering agility). You could grandfather in the initial board members, have them meet every month on a public channel, and log outcomes on a wiki. After a set period of time, open up nominations, and form the first independently elected board.
We did this in Ubuntu. We started with some core governance boards (the Community Council, focused on community policy and the Technical Council focused on technical policy). The rest of the extensive governance structure came as Ubuntu grew significantly. Our goal was always to keep things as lightweight as possible.
Iterate and Improve
I am a firm believer that the way in which we collaborate should be as much of a collaborative product as the output of a community project. Just like an open source project, we should review, iterate, and review the performance of our iterations. We should constantly assess how we can optimize our governance to be as simple and thin as possible. We should build an environment where someone can file a metaphorical or literal pull request with pragmatic ways to optimize how the project is governed. This assures the project is pulling the best insight from members to ensure it is as efficient and as lightweight as possible.
To do this, honestly observe how the governance performs. Is it accomplishing the goals it is designed for? Are governance members enjoying their work and fulfilled in the delivery? Is it supporting the success of community members? Evaluate how the meetings are run, if actions are followed up on, and whether people are late.
On a regular basis (e.g. once a quarter) plan some adjustments and changes based on these observations and track if these changes improve overall performance.
Throughout this process, deliberately practice muntzing (as I wrote about here) to remove anything that isn’t neccessary. This keeps your governance to a minimum and ensures there is a culture of challenging current norms and optimizing how the project works. This ultimately results in healthier more pragmatic communities that still benefit from the many benefits of well-structured governance.
As mentioned previously, I am advisor to a startup called Moltin which provides a simple yet powerful API for building eCommerce solutions in a variety of places. It has the potential to really change how we think of eCommerce transactions, making it easier, more discoverable, and more convenient for consumers, and more effective for organizations to sell products.
I was offered an advisory role a little while back and agreed to to sign on for a few reasons. Firstly, Jamus delivered great results at DemandWare (and as EIN at Underscore.VC, when I first met him). Secondly, their founding team have a great product and community vision, and understand how to run a company. Thirdly, their Series A (and the original introduction) came from Underscore.VC, who I have a great relationship and enormous respect for. Finally, and critically, they are devoted to delivering a solid developer and community experience (which is primarily what I am advising them on). I am only interested in working with companies who want to deliver results, and Moltin are clearly formed into that mold.
Congratulations to the Moltin team. Looking forward to a fruitful 2018!