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!
In musicians circles, the Fractal Audio Systems Axe FX range of products has become one of the most highly regarded product lines. Aside from just being a neat product, what is interesting to me is the relationship they have built with their community and value they have created in the product via sustained software updates.
As a little background, the Axe FX and their other AX8/FX8 floor-board products, are hardware units that replicate in software the characteristics of an analog tube guitar amplifier and speaker cabinets. Now, for years there have been companies (e.g. Line6, IK Multimedia) trying to create a software replication of popular Marshall, Mesa Boogie, Ampeg, Peavey, Fender, and other amp tones, with the idea being that you can spend far less on the software and have a wide range of amps to choose from as well. This not only saves on physical space and dollars, but also simplifies recording these amps as you won’t need to plug in a physical microphone – you just play direct through the software. Sadly, the promise has been largely pretty disappointing. Most generally sound like fizzy, cheap knockoffs.
While this may be a little strange to grok for the non-musicians reading this, but there isn’t just a tonality assessment to determine if the amp simulator sounds like the real thing, but there is a feel element. Tube amps feel different to play. They have tonal characteristics that adjust as you dial in different settings, and one of the tricky elements for amp simulators to solve is that analog tubes adjust as you use them; the tone adjusts in subtle ways depending on what you play, how you play it, which power supply you are using, how you dial in the amp, and more.
The Axe FX changed much of this. While many saw it initially as just another amp simulator, it has evolved to a point where in A/B testing it is virtually indistinguishable from the amps it is modelling tonally, and the feel is very much there too. This is why bands such as Metallica, U2, Periphery, Steve Vai, and others carry them on tour with them: they can accomplish the same tonal and feel results without the big, unreliable, and complex-to-maintain tube amps.
Sustained Software Updates
The reason why this has been such a game changer is that Cliff Chase, founder of Fractal Audio Systems, has taken a borderline obsessive approach to detail in building this amp/speaker modelling and creating a small team to deliver it.
From a technology perspective, this is interesting for a few reasons.
Firstly, Fractal have been fairly open about how their technology has evolved. They published a whitepaper on their MIMIC technology and they have been fairly open about how this modelling technology has evolved. You can see the release notes, some further technical details, and a collection of technical posts by Cliff on the forum.
What I found particularly interesting here was Fractal have consistently delivered these improvements via repeated firmware updates out to existing devices. As an example, the MIMIC technology I mentioned above was a major breakthrough in their technology and really (no pun intended) amped up the simulation quality, but it was delivered as a free firmware update to existing hardware.
Now, many organizations would have seen such a technologically important and significant product iteration software update as an opportunity to either release a new hardware product or sell a new line of firmware at a cost. Fractal didn’t do this and have stuck to their philosophy that when you buy their hardware, it is “future proofed” with firmware updates for years to come.
This is true. As an example, the Axe FX II was released in May 2011 and has received 20+ firmware updates which have significantly improved the quality of the product.
In a technology culture where companies release new-feature software updates for a limited period of time (often 2 – 3 years) and then move firmly into maintenance/security updates for a stated “product life” (often 4 – 7 years), Fractal Audio Systems are bucking this trend significantly.
This regular stream of firmware updates that bring additional value, not just security/compatibility fixes, is notable for a few reasons.
Firstly, it has significantly expanded the lifespan and market impact of these devices. Musicians and producers can be a curmudgeonly bunch, and it can take a while for a product to take hold. This is particularly true in a world where “purism” of the art of creating and producing music, and the purism of the tools you use would ordinarily reject any kind of simulated equipment. The Axe FX has become a staple in touring and production rigs because of it’s constant evolution and improvements.
Secondly, from a consumer perspective, there is something so satisfying about purchasing a hardware product that consistently improves. Psychologically, we are used to software evolving (in either good or bad directions), but hardware has more of a “cast in stone” psychological impression in many of us. We buy it, it provides a function, and we don’t expect it to change much. In the case of the Fractal Audio Systems hardware, it does change, and this provides that all important goal companies focus on: customer delight.
Thirdly, and most interestingly for me, Fractal Audio Systems have fostered a phenomenally devoted, positive, and supportive community. From a community strategy perspective, they have not done anything particularly special: they have a forum, a wiki, and members of the Fractal Audio Systems team post periodically in the forum. They have the usual social media accounts and they release videos on YouTube. This devotion in the community is not from any community engagement fakery…it is from (a) a solid product, and (b) a company who they feel isn’t bullshitting them.
This latter element, the bullshit factor, is key. When I work with my clients I always emphasize the importance of authenticity in the relationship between a company and their community of users/customers. This doesn’t mean pandering to the community and the critics, it means an honest exchange of ideas and discussion in which the company and the community/users can derive equal levels of value out of the relationship.
In my observation of the Fractal Audio Systems community, they have done just this. Cliff Chase, as the supreme leader at Fractal Audio Systems is revered in the community as a mastermind, a reputation that is rightly earned. He is an active participant with the community, sharing his input both on the musical use of his products as well as the technology that has gone into them. He isn’t a CEO who is propped up on conference stages or bouncing from journalist to journalist merely talking about vision, he is knee-deep, sleeves rolled fully-up, working on improvements that then get rolled out…freely…to an excitable community of users.
This puts the community in a valuable position. They become the logical feedback loop (again, no pun intended) for how well the products and firmware updates are working, and while the community can’t participate in improving the products directly (as they don’t have access to the code or in many cases, the skills to contribute) they get to see the fruits of their feedback in these firmware updates.
This serves two important benefits. Firstly, validation is an enormous force in what we do. Everyone, no matter who you are, needs validation of their input and ideas. When the community share feedback that is then validated by Cliff and co., and then rolled out in a freely available firmware update that benefits everyone, this is a deeply satisfying experience. Secondly, in many communities there is a suspicion about providing value (such as feedback or other technical contributions) to a company if only the company benefits from this (e.g. by selling a new product encompassing that feedback). Given that Fractal Audio Systems pushes out these updates freely, it largely eradicates that issue.
Everything I have outlined here could be construed as a master plan on behalf of the folks at Fractal Audio Systems. I don’t think this is the case. I don’t believe that when Cliff Chase founded the company he layed all of this out as a grand plan for how to build community and customer engagement.
This goes back to purity. My guess is that Cliff and team just wanted to build a solid product that makes their customers happy and providing this regular stream of updates was the most obvious way to do it. It wouldn’t surprise me if they themselves were surprised by how much goodwill would be generated throughout this process.
This is all paving away to the next iteration of this journey, when the Axe FX III was announced last week. It provides significantly greater horsepower, undoubtedly to usher in the next era of improvements. This is a journey I will be following along with when I get an Axe FX III of my own in March.