In recent years innersource is a term that has cropped up more and more. As with all new things in technology, there has been a healthy mix of interest and suspicion around what exactly innersource is (and what it isn’t).
As a consultant I work with a range of organizations, large and small, across various markets (e.g. financial services, technology etc) to help them bring innersource into their world. So, here is a quick guide to what innersource is, why you might care, and how to get started.
What is Innnersource?
In a nutshell, ‘innersource’ refers to bringing the core principles of open source and community collaboration within the walls of an organization. This involves building an internal community, collaborative engineering workflow, and culture.
This work happens entirely within the walls of the company. For all intents and purposes, the company develops an open source culture, but entirely focused on their own intellectual property, technology, and teams. This provides the benefits of open source collaboration, community, and digital transformation, but in a safe environment, particularly for highly regulated industries such as financial services.
Innersource is not a product or service that you buy and install on your network. It is instead a term that refers to the overall workflow, methodology, community, and culture that optimizes an organization for open source style collaboration.
Why do people Innersource?
Many organizations are very command-and-control driven, often as a result of their industry (e.g. highly regulated industries), the size of the organization, or how long they have been around.
Command-and-control driven organizations often hit a bottleneck in efficiency which results in some negative outcomes such as slower Time To Market, additional bureaucracy, staff frustration, reduced innovation, loss of a competitive edge, and additional costs (and waste) for operating the overall business.
An unfortunate side effect of this is that teams get siloed, and this results in reduced collaboration between projects and teams, duplication of effort, poor communication of wider company strategic goals, territorial leadership setting in, and frankly…the organization becomes a less fun and inspiring place to work.
While the benefits of open source have been clearly felt in reducing costs for consuming and building software and services, there has also been substantive value for organizations and staff who work together using an open source methodology. People feel more engaged, are able to grow their technical skills, build more effective relationships, feel their work has more impact and meaning, and experience more engagement in their work.
It is very important to note that innersource is not merely about optimizing how people write code. Sure, workflow is a key component, but innersource is fundamentally cultural in focus. You need both: If you build an environment that (a) has an open and efficient peer-review based workflow. and (b) you build a culture that supports cross-departmental collaboration and internal community, the tangible output is unsurprisingly, not just better code, but better teams, and better products.
What are the BENEFITS of innersource for an organization?
There are number of benefits for organizations that work in an innersource way:
- Faster Time To Market (TTM) – innersource optimizes teams to work faster and more efficiently and this reduces the time it takes to build and release new products and services.
- Better code – a collaborative peer-review process commonly results in better quality code as multiple engineers are reviewing the code for quality, optimization, and elegance.
- Better security – with more eyeballs on code due to increased collaboration, all bugs (and security flaws) are shallow. This means that issues can be identified more quickly, and thus fixed.
- Expanded innovation – you can’t successfully “tell” people to innovate. You have to build an environment that encourages employees to have and share ideas, experiment with prototypes, and collaborate together. Innersource optimizes an organization for this and the result is a permissive environment that facilitates greater innovation.
- Easier hiring – young engineers are growing up in a world where they can cut their teeth on open source projects to build up their experience. Consequently, they don’t want to work in dusty siloed organizations, they want to work in an open source way. Innersource (as well as wider open source participation) not only makes your company more attractive, but it is increasingly a requirement to attract the best talent.
- Improved skills development – with such a focus on collaboration with innersource, staff learn from each other, discover new approaches, and rectify bad habits due to peer review.
- Easier performance/audit/root cause analysis – innersource workflow results in a digital record of your entire collaborative work. This can make tracking performance, audits, and root cause analysis easier. Your organization benefits from a record of how previous work was done which can inform and illustrate future decisions.
- More efficient on-boarding for new staff – when new team members join the company, this record of work I outlined in the previous bullet helps them to see and learn from how previous decisions were made and how previous work was executed. This makes on-boarding, skills development, and learning the culture and personalities of an organization much easier.
- Easier collaboration with the public open source world – while today you may have no public open source contributions to make, if in the future you decide to either contribute to or build a public open source project, innersource will already instill the necessary workflow, process, and skills to work with public open source projects well.
What are the RISKS of innersource for an organization?
While innersource has many benefits, it is not a silver bullet. As I mentioned earlier, innersource is fundamentally about building culture, and a workflow and methodology that provides practical execution and delivery.
Building culture is hard. Here are some of the risks attached:
- It takes time – putting innersource in place takes time. I always recommend organizations to start small and iterate. As such, various people in the organization (e.g. execs and key stakeholders) will need to ensure they have realistic expectations about the delivery of this work.
- It can cause uncertainty – bringing in any new workflow and culture can cause people to feel anxious. It is always important to involve people in the formation and iteration of innersource, communicate extensively, reassure, and always be receptive to feedback
- Purely top-down directives are often not taken seriously – innersource requires both a top-down permissive component from senior staff and bottom-up tangible projects and workflow for people to engage with. If one or the other is missing, there is a risk of failure.
- It varies from organization to organization – while the principles of innersource are often somewhat consistent, every organization’s starting point is different. As such, delivering this work will require a lot of nuance for the specifics of that organization, and you can’t merely replicate what others have done.
How do I use Innersource at my company?
In the interests of keeping this post concise, I am not going to explain here how to build out an innersource program here, but to share some links some other articles I have written for how to get started:
- How to create an internal innersource community
- 10 steps to innersource in your organization
- Building better teams with asynchronous workflow
One thing I would definitely recommend is hiring someone to help you with this work. While not critical, there is a lot of nuance attached to building the right mix of workflow, incentives, messaging, and building institutional knowledge. Obviously, this is something I provide as a consultant (more details), so if you want to discuss this further, just drop me a line.
I am going to be honest with you, I am writing this post out of one part frustration and one part guidance to people who I think may be inadvertently making a mistake. I wanted to write this up as a blog post so I can send it to people when I see this happening.
It goes like this: when I follow someone on Twitter, I often get an automated Direct Message which looks something along these lines:
These messages invariably are either trying to (a) get me to look at a product they have created, (b) trying to get me to go to their website, or (c) trying to get me to follow them somewhere else such as LinkedIn.
Unfortunately, there are two similar approaches which I think are also problematic.
Firstly, some people will have an automated tweet go out (publicly) that “thanks” me for following them (as best an automated bot who doesn’t know me can thank me).
Secondly, some people will even go so far as to record a little video that personally welcomes me to their Twitter account. This is usually less than a minute long and again is published as an integrated video in a public tweet.
Why you shouldn’t do this
There are a few reasons why you might want to reconsider this:
Firstly, automated Direct Messages come across as spammy. Sure, I chose to follow you, but if my first interaction with you is advertising, it doesn’t leave a great taste in my mouth. If you are going to DM me, send me a personal message from you, not a bot (or not at all). Definitely don’t try to make that bot seem like a human: much like someone trying to suppress a yawn, we can all see it, and it looks weird.
Secondly, don’t send out the automated thank-you tweets to your public Twitter feed. This is just noise that everyone other than the people you tagged won’t care about. If you generate too much noise, people will stop following you.
Thirdly, in terms of the personal video messages (and in a similar way to the automated public thank-you messages), in addition to the noise it all seems a little…well, desperate. People can sniff desperation a mile off: if someone follows you, be confident in your value to them. Wow them with great content and interesting ideas, not fabricated personal thank-you messages delivered by a bot.
What underlies all of this is that most people want authentic human engagement. While it is perfectly fine to pre-schedule content for publication (e.g. lots of people use Buffer to have a regular drip-feed of content), automating human engagement just doesn’t hit the mark with authenticity. There is an uncanny valley that people can almost always sniff out when you try to make an automated message seem like a personal interaction.
Of course, many of the folks who do these things are perfectly well intentioned and are just trying to optimize their social media presence. Instead of doing the above things, see my 10 recommendations for social media as a starting point, and explore some other ways to engage your audience well and build growth.
See my new post for opensource.com about how you build culture in an organization/community:
“Culture” is a pretty ambiguous word. Sure, reams of social science research explore exactly what exactly “culture” is, but to the average Joe and Josephine the word really means something different than it does to academics. In most scenarios, “culture” seems to map more closely to something like “the set of social norms and expectations in a group of people.” By extension, then, an “IT culture” is simply “the set of social norms and expectations pertinent to a group of people working in an IT organization.”
I suspect most people see themselves as somewhat passive contributors to this thing called “culture.” Sure, we know we can all contribute to cultural change, but I don’t think most people actually feel particularly empowered to make this kind of meaningful change. On top of that, we can also observe significant changes in cultural norms that depend on variables like time and geography. An IT company in China, for example, might have a very different culture from a company in the San Francisco area. A startup in Birmingham, England will have a different culture to a similar startup in Berlin, Germany. And so on.
Culture is critical. It’s the lifeblood of an organization, but it’s complicated to understand and shape. The “IT culture” of the 1980s and 1990s differs from “IT culture” today—and it will be different again 10 years from now. Apart from generational changes, cultural norms for IT practitioners have changed, too. Today, digital technology is more social, more accessible to people with fewer technical skills, and more embedded in our consumer-oriented world than ever. We’ve learned to cherish simplicity, elegance, and design, and this has reflected the kinds of organizations that are forming.
Read it here.
Back in the 40s, TVs were giant, ugly behemoths. They were jammed with vacuum tubes, big bulky components, and were prone to overheating and failure.
Earl “madman” Muntz was an engineer and businessman who started repairing radios when he was 8 and built his first car radio when he was 14. As only someone with the nickname ‘madman‘ could do, when he worked in the TV business, he would walk around the factory floor, step in front of an unsuspecting engineer and yank components from TV sets until they stopped working. Then, he would put the last removed component back in and the set would often work, but with fewer components (thus cheaper) and often other benefits such as reduced heat.
This practice became known as muntzing, which while it sounds like some awful way of hazing people with a hosepipe, it was actually a deliciously simple exercise in efficiency and cost reduction. Rather unsurprisingly, this provides an interesting lesson we can apply outside of knackered, old TVs from the forties.
Simple but not Simpler
Muntz’ was fundamentally zoning in on simplicity as a way to accomplish efficiency.
He wasn’t the first. Around the same time period, Einstein, a man not especially unfamiliar with genius, said:
“Everything should be made as simple as possible, but not simpler.”
Einstein touches on the elegance in simplicity and not to be fooled by thinking simple minds create simple things. We see this every day with seemingly simple devices (e.g. the iPhone) that carefully conceal enormous amounts of complexity behind the scenes, both in terms of technology and workflow.
For the work I do in building productive and engaging communities and organizations, this is nirvana. My ultimate goal is to build human systems that deliver solid, productive, and predictable results but are simple in their instrumentation and use. As you can imagine, there is often a lot of complexity that goes into doing this.
So, Muntz and Einstein give us a good recipe: focus on simplicity as a means to accomplish efficiency, and reduce the complexity as a means to become lean. Sounds great in theory, but how do we do this?
Harnessing Adversity to Build Efficiency
There are various reasons why things become inefficient: people get lazy and take shortcuts, complexity slows things down, too many layers of abstraction contribute to this complexity, people accept the new reality of inefficiency and don’t challenge it…the list goes on.
We see this everywhere in the products we build, the organizational methodologies we have in companies and communities, the systems we have to use to file our taxes or invoices, and elsewhere. Not seen this? Go to the DMV in America. You will get it in droves.
An effective way to create efficiency and optimization is when we have manageable adversity. That is, we face tough situations that are within our control, capability, and power to resolve and learn from.
Muhammed Ali said it best:
“I don’t count my situps, I only start counting when it starts hurting, when I feel pain, that’s when I start counting, cause that’s when it really counts.”
Our most difficult moments in life, when we can feel beaten down, tired, and lost, can be the most formidable times of personal growth, evolution, and development. If we therefore instill the right level of adversity into our work, complete with having the ability to resolve it (which is the key difference between adversity being a helpful thing or a discriminatory force), we develop efficiencies.
Putting This Into Practice
As such, there can be enormous value in deliberately injecting adversity into our work as a forcing function to get better results. In other words, sometimes the easiest path forward is not the best path if we want to increase our capability and creativity. Sometimes throwing a few obstacles people need to navigate can be a useful thing.
Here are five recommendations to consider.
1. Add intentional burdens
Baseball players would use two bats, drummers would put additional weights on their ankles, and powerlifters would lift additional weight beyond competition requirements all for the same reason: when you remove the additional burden, your performance improves.
Think about how you can instill an intentional restriction that will force you and your teammates to think creatively around how to solve the problem.
For example, an ex-colleague of mine at Canonical was once facing a very low-level bug in the Linux kernel, before the screen was powered up. As such he saw no error messages to indicate the issue. His solution? He wrote a kernel driver to flash the caps lock light in morse and used a sensor sat on the light to read in the morse to see the issue.
He faced a burden, and that burden generated a creative solution. In a similar way, Steve Jobs famously demanded Burrell Smith accomplish his vision of the first Macintosh with fewer hardware components than he had available. These burdens generated remarkable outcomes.
2. Require an ambitious metric
Create an ambitious metric that a solution is required to accomplish. It is incredible what people will do to accomplish a given metric, be it a score in a video game, a measurement on a device, or a target weight to get into a suit at a wedding (ahem!).
A good example here was the first XPRIZE (I used to work at XPRIZE a few years back). A $10million prize would be awarded to a team who built a reusable spacecraft that could go up into space and back, twice in two weeks.
This ambitious requirement to win the competition made teams think creatively across a wide range of engineering challenges to accomplish the goal. The result: the birth of commercial space travel development.
Think about how you place an ambitious requirement for the outcome of a particular project, and one that really helps the team to focus on accomplishing that goal in a creative, lean, and ambitious way.
3. Iterate and optimize
An approach I use throughout my work is to break work down into smaller pieces to (a) generate data we can use to assess the success or failure of a project, and (b) to use that data to iterate, improve, and test again.
This is one of the most fundamentally important approaches to evolving any kind of product or process: we can’t improve without information and iteration. As one consideration when iterating, always ask the question “how can we do more with less?”. Tiny improvements and efficiencies on a regular cadence will stack up and deliver incredible overall results.
4. Focus on creative solutions
This may seem a little generic, but all too often we constrain our thinking with existing ways of working.
As an example, one company I have worked with wanted to get a complex developer platform online quickly. The engineering team drafted a plan to build a complex infrastructure, complete with APIs, and a difficult to understand process for using it.
The founder responded with “just put a damn web server online and let people upload files”. He was right: as a minimum viable product (for a young, and potentially experimental project), he wanted to focus on shipping something that worked.
As Reed Hoffman, founder of LinkedIn once famously said:
“If You’re Not Embarrassed By The First Version Of Your Product, You’ve Launched Too Late”.
Reed is right. Be like Reed.
5. Build a hackable culture
If there is one thing I have learned about innovation over the years is that you can’t predict where it comes from. One such example is Jack Andraka, who invented a cheaper and more effective pancreatic cancer test when he was at high school.
You can’t instruct someone to be innovative, but you can build a culture that encourages and allows people to innovate. Innovation requires permission to flourish, and to accomplish this, you need to encourage and allow people to produce interesting hacks that do interesting things.
Encourage your teams to explore new ideas, build them, and demo them. Encourage people to hack on and improve products and services as proof of concepts. If you have a permissive environment that encourages people to hack, explore, and be creative, you will get that same kind of ethos when you create production products and services.
This can be nerve-wracking for some companies because it can feel like it encourages people to challenge the norms of the company. It does, and that is a good thing. Part of being a hackable culture is to actively encourage people to call you on your bullshit and propose better, more efficient, and more interesting solutions.
I would LOVE to hear your thoughts here. What do you think of these recommendations? Do you agree or disagree with them? Can they be improved? How else can we build better things? Share your ideas and feedback in the comments below…
A few weeks ago I spoke at DevXCon in San Francisco. I delivered a keynote about measuring the health of a community and how we can tie effective measurements into community reputation, incentives, and other elements. In that talk I touched on the importance of validation and decay and I wanted to take a moment to explain what these concepts are and why they are important.
Firstly, there are two categories of things we can measure in communities:
- Tangible – these are the things we can measure with computers such as messages, pull requests, issues, questions posted to websites, questions answered etc.
- Intangible – these are the analogue things associated with humans that are more complex to measure such as satisfaction, happiness, motivation, respect etc.
Today I want to focus on the tangible (I will cover the intangible side in a future post).
When measuring tangible participation in a community (such as organizing events, contributing code, playing a game, or something else), various communities will generate a “reputation” score that reflects the aggregate set of contributions. The way this is presented varies in different communities.
For example, Battlefield 4 awards you various points based upon your skill demonstrated in the game, ultimately rolling up to your score:
HackerOne (a service for vulnerability report submission and bounties) takes a slightly different approach and actually presents three scores:
Here, reputation covers the total points given for submitted reports, signal covers the average points awarded for a reviewed report, and impact covers points awarded to programs with bounties.
This doesn’t show an individual score for each user but instead shows which users share similar levels of activity and participation.
There are benefits and disadvantages to all of these approaches, but there is clearly value in generating some kind of numerical representation of quality of participation. It can provide a useful way of engaging with community members, providing rewards, opening up additional opportunities, and more.
Activity and Validation
The tricky thing with measuring participation is that you run the risk of people gaming the system.
A classic example of this was some of the older forum platforms. With some (such as phpBB) you could set ranks based upon the number of posts made to the forum. So for example, you may have these labels next to a forum user based on the threshold of posts to the forum:
- < 100 = Newbie
- 100 – 500 = Regular
- 500 – 1500 = Rockstar
- 1500+ = Epic
As you can imagine, some people would deliberately post small and pointless replies to these forums. I recently interviewed Jeff Atwood, who I consider to be one of the brightest minds on building collaborative platforms, and he summed it up well:
Remember, whenever you put a number next to someone’s name, you are now playing with dynamite. People will do whatever they can to make that number go up, even if it makes no sense at all, or has long since stopped being reasonable. Carefully consider all the implications of that number carefully before you put it anywhere, and take a moment to think about what Evil People will do with it, as well.
One way in which I like to think of measuring things is to measure two components: the activity and the validation of that activity. This provides the ability for us to not just count the number of contributions (which is helpful in determining the level of activity and for how long), but also if another member of the community has determined it to be valuable, which can be a good indicator of quality.
We already see this in the HackerOne example above. The reputation score is a good indicator of the level of activity, but some users may “shotgun” low quality reports to get their reputation score. This is where the signal number comes in: it shows the average quality for reports, so the higher number, the better the overall report quality from that hacker.
In the software development world the key example of this is a merged pull request. It is one thing for someone to submit code for review for inclusion in a project, but a merged pull request shows that (a) someone contributed code, (b) it was reviewed by their peers, (c) it was deemed high quality, and (d) it added value to the project and was thus merged.
We can explore all kinds of way of validating contributions and they don’t have to be heavyweight. How many messages have received a like? How many people upvoted a question? How many people showed up to a meetup? Even lightweight ways of determining a simple level of validation can be helpful.
It is essential to track both. If you only track activity, the system can be gamed. If you track validation too, you can more intelligently interpret the data.
Fairness and Decay
Rather unsurprisingly, when you start tracking reputation in some form, there is a temptation to build leaderboards to instill a little competitive spirit for people to see who can get their scores the highest. While this varies from community to community, it works. People love to compete, and it can be a fun way to encourage people to improve their skills or participate more.
A core goal I have when I build communities for organizations is that community strategy should encourage the right kind of behaviors. We want to build systems and processes that get people participating in a positive way.
I like to approach community strategy with the goal of creating significant and sustained participation that builds a sense of belonging. We don’t just want drive-by participation, we want people to stick around for long periods of time, and to do that there is a strong psychological desire for people to build a sense of respect and status in the community. For them to accomplish this, we need to prevent our communities from being a place where the rockstars (who have done great work for many years) can never be unseated from their pedestals.
This is why decay is so important. When you have a reputation score, it is important that the score will gradually decrease with lack of participation over time. This should not be too quick, we need to allow people to take time away, have vacations, have kids, or other time away, and not have their hard earned reputation points evaporate.
It is though important to gradually decrease reputation scores from inactivity for two important reasons though:
- If you don’t, your community will be rigged. Anyone who is newer than being right at the beginning of the community will literally never be able to catch up. It will reward the early participants unfairly.
- Your community will also lack a forcing function to encourage people to be actively participating. The inverse of this forcing function is that people will feel they can coast and still have a very respectful reputation score.
Of course, there are no hard rules in any of this, but I recommend you apply these guidelines when thinking about generating reputation scores. The most important thing to focus on is that your scores are fair, they can’t be gamed in an undesirable way, and they reward people for quality participation.
What do you think? Do you have further recommendations or ideas you want to share? Did I say something you want to challenge? Share it in the comments below…
Recently I got a Google Home (thanks to Google for the kind gift). Last week I recorded a quick video of me interrogating it:
Well, tonight I nipped upstairs quickly to go and grab something and as I came back downstairs I heard Jack, our vivacious 4-year-old asking it questions, seemingly not expecting daddy to be listening.
This is when I discovered the wild curiosity in a 4-year-old’s mind. It included such size and weight questions as…
OK Google, how big is the biggest teddy bear?
OK Google, how much does my foot weigh?
…to curiosities about physics…
OK Google, can chickens fly faster than space rockets?
…to queries about his family…
OK Google, is daddy a mommy?
…and while asking this question he interrupted Google’s denial of an answer with…
OK Google, has daddy eaten a giant football?
Jack then switched gears a little bit, out of likely frustration that Google seemed to “not have an answer for that yet” to all of his questions, and figured the more confusing the question, the more likely that talking thing in the kitchen would work:
OK Google, does a guitar make a hggghghghgghgghggghghg sound?
Google was predictably stumped with the answer. So, in classic Jack fashion, the retort was:
OK Google, banana peel.
While this may seem random, it isn’t:
I would love to see the world through his eyes, it must be glorious.
This coming weekend is the Community Leadership Summit in Austin (I hope to see you all there!), but there is another event I am running which you need to know about.
The Open Community Conference is one of the four main events that is part of the Open Source Summit in Los Angeles from 11th – 13th September 2017. A little while ago the Linux Foundation and I started exploring running a new conference as part of their Open Source Summit, and this has culminated in the Open Community Conference.
The goals of the event are simple: to provide presentations, panels, and networking that share community management and leadership best practice in a practical and applicable way. My main goal is to provide a set of speakers who have built great communities, either internally or externally, and have them share their insights.
This is different to the Community Leadership Summit: CLS is a set of discussions designed for community managers. The Open Community Conference is a traditional conference with presentations, panels, and more in which methods, approaches, case-studies, and more is shared, and designed for a broader audience.
Call For Papers
If you have built community in the open source world, or have built internal communities using open source methodologies, I would love to have you submit a paper by clicking here. The call for papers closes THIS WEEK on 6th May 2017, so get them in!
He made it clear he is not advocating for this view, just a thought experiment. I had, well, a few thoughts on this.
I tend to think of open source projects in three broad buckets.
Firstly, we have the overall workflow in which the community works together to build things. This is your code review processes, issue management, translations workflow, event strategy, governance, and other pieces.
Secondly, there are the individual contributions. This is how we assess what we want to build, what quality looks like, how we build modularity, and other elements.
Thirdly, there is identity which covers the identity of the project and the individuals who contribute to it. Solomon taps into this third component.
While the first two components, workflow and contributions are clearly important in defining what you want to work on and how you build it, identity is more subtle.
I think identity plays a few different roles at the individual level.
Firstly, it helps to build reputation. Open source communities are at a core level meritocracies: contributions are assessed on their value, and the overall value of the contributor is based on their merits. Now, yes, I know some of you will balk at whether open source communities are actually meritocracies. The thing is, too many people treat “meritocracy” as a framework or model: it isn’t. It is more of a philosophy…a star that we move towards.
It is impossible to build a meritocracy without some form of identity attached to the contribution. We need to have a mapping between each contribution and the same identity that delivered it: this helps that individual build their reputation as they deliver more and more contributions. This also helps them flow from being a new contributor, to a regular, and then to a leader.
This leads to my second point. Identity is also critical for accountability. Now, when I say accountability we tend to think of someone being responsible for their actions. Sure, this is the case, but accountability also plays an important and healthy role in people receiving peer feedback on their work.Open source communities are kinda weird places to be. It is easy to forget that (a) joining a community, (b) making a contribution, (c) asking for help, (d) having your contribution critically reviewed, and (e) solving problems, all happens out in the open, for all to see. This can be remarkably weird and stressful for people new to or unfamiliar with open source, and on a bed of the cornucopia of human insecurities about looking stupid, embarrassing yourself etc. While I have never been to one (honest), I imagine this is what it must be like going to a nudist colony: everything out on display, both good and bad.
All of this rolls up to identity playing an important role for building the fabric of a community, for effective peer review, and the overall growth of individual participants (and thus the network effect of the community).
Real Names vs. Handles
If we therefore presume identity is important, do we require that identity to be a real name (e.g. “Jono Bacon”) or a handle (e.g. “MetalDude666”)? – not my actual handle, btw.
In terms of the areas I presented above such as building reputation, accountability, and peer review, this can all be accomplished if people use handles, under the prerequisite that there is some way of knowing that “MetalDude666” is the same person each time. Many gaming communities have players who build remarkable reputations and accountability and no one knows who they really are, just their handles.
Where things get trickier is assuring the same quality of community experience for those who use real names and those who use handles in the same community. On core infrastructure (such as code hosting, communication channels, websites, etc) this can typically be assured. It can get trickier with areas such as real-world events. For example, if the community has an in-person event, the folks with the handles may not feel comfortable attending so as to preserve their anonymity. Given how key these kinds of events can be to building relationships, it can therefore result in a social/collaborative delta between those with real names and those with handles.
So, in answer to Solomon’s question, I do think identity is critical, but it could be all handles if required. What is key is to either (a) require only handles/real names (which is tough), or (b) provide very careful community strategy and execution to reduce the delta of experience between those with real names and handles (tough, but easier).
So, what do you think, folks? Do you agree with me, or am I speaking nonsense? Can you share great examples of anonymous of open source communities? Are there elements I missed out in my assessment here? Share them in the comments below!
I wrote this on G+, but it seemed appropriate to share it here too:
So, today Canonical decided to refocus their business and move away from convergence and devices. This means that the Ubuntu desktop will move back to GNOME.
I have seen various responses to this news. Some sad that it is the end of an era, and a non-zero amount of “we told you so” smugness.
While Unity didn’t pan out, and there were many good steps and missteps along the way, I am proud that Canonical tried to innovate. Innovation is tough and fraught with risk. The Linux desktop has always been a tough nut to crack, and one filled with an army of voices, but I am proud Canonical gave it a shot even if it didn’t succeed it’s ultimate goals. That spirit of experimentation is at the epicenter of open source, and I hope everyone involved here takes a good look at how they contributed to and exacerbated this innovation. I know I have looked inwards at this.
Much as some critics may deny, everyone I know who worked on Unity and Mir, across engineering, product, community, design, translations, QA, and beyond did so with big hearts and open minds. I just hope we see that talent and passion continue to thrive and we continue to see Ubuntu as a powerful driver for the Linux desktop. I am excited to see how this work manifests in GNOME, which has been doing some awesome work in recent years.
And, Mark, Jane, I know this will have been a tough decision to come to, and this will be a tough day for the different teams affected. Hang in there: Ubuntu has had such a profound impact on open source and while the future path may be a little different, I am certain it will be fruitful.