For some time now I have been working with HackerOne to help them shape and grow their hacker community. It has been a pleasure working with the team: they are doing great work, have fantastic leadership (including my friend, Mårten Mickos), are seeing consistent growth, and recently closed a $40 million round of funding. It is all systems go.
For those of you unfamiliar with HackerOne, they provide a powerful vulnerability coordination platform and a global community of hackers. Put simply, a company or project (such as Starbucks, Uber, GitHub, the US Army, etc) invite hackers to hack their products/services to find security issues, and HackerOne provides a platform for the submission, coordination, dupe detection, and triage of these issues, and other related functionality.
You can think of HackerOne in two pieces: a powerful platform for managing security vulnerabilities and a global community of hackers who use the platform to make the Internet safer and in many cases, make money. This effectively crowd-sources security using the same “with enough eyeballs are shallow” principle in open source: with enough eyeballs all security issues are shallow too.
HackerOne and Open Source
HackerOne unsurprisingly are big fans of open source. The CEO, Mårten Mickos, has led a number of successful open source companies including MySQL and Eucalyptus. The platform itself is built on top of chunks of open source, and HackerOne is a key participant in the Internet Bug Bounty program that helps to ensure core pieces of technology that power the Internet are kept secure.
One of the goals I have had in my work with HackerOne is to build an even closer bridge between HackerOne and the open source community. I am delighted to share the next iteration of this.
HackerOne for Open Source Projects
While not formally announced yet (this is coming soon), I am pleased to share the availability of HackerOne Community Edition.
Put simply, HackerOne is providing their HackerOne Professional service for free to open source projects.
This provides features such as a security page, vulnerability submission/coordination, duplicate detection, hacker reputation, a comprehensive API, analytics, CVEs, and more.
This not only provides a great platform for open source projects to gather vulnerability report and manage them, but also opens your project up to thousands of security researchers who can help identify security issues and make your code more secure.
Which projects are eligible?
To be eligible for this free service projects need to meet the following criteria:
- Open Source projects – projects in scope must only be Open Source projects that are covered by an OSI license.
- Be ready – projects must be active and at least 3 months old (age is defined by shipped releases/code contributions).
- Create a policy – you add a
SECURITY.mdin your project root that provides details for how to submit vulnerabilities (example).
- Advertise your program – display a link to your HackerOne profile from either the primary or secondary navigation on your project’s website.
- Be active – you maintain an initial response to new reports of less than a week.
If you meet these criteria and would like to apply, just see the HackerOne Community Edition page and click the button to apply.
Of course, let me know if you have any questions!
My work with them has primarily been involved in the community and product development of an initiative in which they are integrating functionality into the operating system that teaches you how to code. This provides a powerful platform where you can learn to code and easily hack on applications in the platform.
If this sounds interesting to you, I created a short video demo where I show off their Mission hardware as well as run through a demo of Endless Code in action. You can see it below:
I would love to hear what you think and how Endless Code can be improved in the comments below.
Early next year Erica, the scamp, and I are likely to be moving house. As part of the move we would both love to turn this house into a smart home.
Now, when I say “smart home”, I don’t mean this:
We don’t need any holographic dogs. We are however interested in having cameras, lights, audio, screens, and other elements in the house connected and controlled in different ways. I really like the idea of the house being naturally responsive to us in different scenarios.
In other houses I have seen people with custom lighting patterns (e.g. work, party, romantic dinner), sensors on gates that trigger alarms/notifications, audio that follows you around the house, notifications on visible screens, and other features.
Obviously we will want all of this to be (a) secure, (b) reliable, and (c) simple to use. While we want a smart home, I don’t particularly want to have to learn a million details to set it up.
Can you help?
So, this is what we would like to explore.
Now, I would love to ask you folks two questions:
- What kind of smart-home functionality and features have you implemented in your house (in other words, what neat things can you do?)
- What hardware and software do you recommend for rigging a home up as a smarthome. I would ideally like to keep re-wiring to a minimum. Assume I have nothing already, so recommendations for cameras, light-switches, hubs, and anything else is much appreciated.
If you have something you would like to share, please plonk it into the comment box below. Thanks!
One of the core principles of open source and innersource communities is asynchronous workflow. That is, participants/employees should be able to collaborate together with ubiquitous access, from anywhere, at any time.
As a practical example, at a previous company I worked at, pretty much everything lived in GitHub. Not just the code for the various products, but also material and discussions from the legal, sales, HR, business development, and other teams.
This offered a number of benefits for both employees and the company:
- History – all projects, discussions, and collaboration was recorded. This provided a wealth of material for understanding prior decisions, work, and relationships.
- Transparency – transparency is something most employees welcome and this was the case here where all employees felt a sense of connection to work across the company.
- Communication – with everyone using the same platform it meant that it was easier for people to communicate clearly and consistently and to see the full scope of a discussion/project when pulled in.
- Accountability – sunlight is the best disinfectant and having all projects, discussions, and work items/commitments, available in the platform ensured people were accountable in both their work and commitments.
- Collaboration – this platform made it easier for people to not just collaborate (e.g. issues and pull requests) but also to bring in other employees by referencing their username (e.g.
- Reduced Silos – the above factors reduced the silos in the company and resulted in wider cross-team collaboration.
- Untethered Working – because everything was online and not buried in private meetings and notes, this meant employees could be productive at home, on the road, or outside of office hours (often when riddled with jetlag at 3am!)
- Internationally Minded – this also made it easier to work with an international audience, crossing different timezones and geographical regions.
While asynchronous workflow is not perfect, it offers clear benefits for a company and is a core component for integrating open source methodology and workflows (also known as innersource) into an organization.
Asynchronous workflow is a common area in which I work with companies. As such, I thought I would write up some lessons learned that may be helpful for you folks.
Designing Asynchronous Workflow
Many of you reading this will likely want to bring in the above benefits to your own organization too. You likely have an existing workflow which will be a mixture of (a) in-person meetings, (b) remote conference/video calls, (c) various platforms for tracking tasks, and (d) various collaboration and communication tools.
As with any organizational change and management, culture lies at the core. Putting platforms in place is the easy bit: adapting those platforms to the needs, desires, and uncertainties that live in people is where the hard work lays.
In designing asynchronous workflow you will need to make the transition from your existing culture and workflow to a new way of working. Ultimately this is about designing workflow that generates behaviors we want to see (e.g. collaboration, open discussion, efficient working) and behaviors we want to deter (e.g. silos, land-grabbing, power-plays etc).
Influencing these behaviors will include platforms, processes, relationships, and more. You will need to take a gradual, thoughtful, and transparent approach in designing how these different pieces fit together and how you make the change in a way that teams are engaged in.
I recommend you manage this in the following way (in order):
- Survey the current culture – first, you need to understand your current environment. How technically savvy are your employees? How dependent on meetings are they? What are the natural connections between teams, and where are the divisions? With a mixture of (a) employee surveys, and (b) observational and quantitive data, summarize these dynamics into lists of “Behaviors to Improve” and “Behaviors to Preserve”. These lists will give us a sense of how we want to build a workflow that is mindful of these behaviors and adjusts them where we see fit.
- Design an asynchronous environment – based on this research, put together a proposed plan for some changes you want to make to be more asynchronous. This should cover platform choices, changes to processes/policies, and roll-out plan. Divide this plan up in priority order for which pieces you want to deliver in which order.
- Get buy-in – next we need to build buy-in in senior management, team leads, and with employees. Ideally this process should be as open as possible with a final call for input from the wider employee-base. This is a key part of making teams feel part of the process.
- Roll out in phases – now, based on your defined priorities in the design, gradually roll out the plan. As you do so, provide regular updates on this work across the company (you should include metrics of the value this work is driving in these updates).
- Regularly survey users – at regular check-points survey the users of the different systems you put in place. Give them express permission to be critical – we want this criticism to help us refine and make changes to the plan.
Of course, this is a simplication of the work that needs to happen, but it covers the key markers that need to be in place.
The specific choices in your own asynchronous workflow plan will be very specific to your organization. Every org is different, has different drivers, people, and focus, so it is impossible to make a generalized set of strategic, platform, and process recommendations. Of course, if you want to discuss your organization’s needs specifically, feel free to get in touch.
For the purposes of this piece though, and to serve as many of you as possible, I want to share the core asynchronous principles you should consider when designing your asynchronous workflow. These principles are pretty consistent across most organizations I have seen.
Be Explicitly Permissive
A fundamental principle of asynchronous working (and more broadly in innersource) is that employees have explicit permission to (a) contribute across different projects/teams, (b) explore new ideas and creative solutions to problems, and (c) challenge existing norms and strategy.
Now, this doesn’t mean it is a free for all. Employees will have work assigned to them and milestones to accomplish, but being permissive about the above areas will crisply define the behavior the organization wants to see in employees.
In some organizations the senior management team spoo forth said permission and expect it to stick. While this top-down permission and validation is key, it is also critical that team leads, middle managers, and others support this permissive principle in day-to-day work.
People change and cultures develop by others delivering behavioral patterns that become accepted in the current social structure. Thus, you need to encourage people to work across projects, explore new ideas, and challenge the norm, and validate that behavior publicly when it occurs. This is how we make culture stick.
Default to Open Access
Where possible, teams and users should default to open visibility for projects, communication, issues, and other material. Achieving this requires not just default access controls to be open, but also setting the cultural and organization expectation that material should be open for all employees.
Of course, you should trust your employees to use their judgement too. Some efforts will require private discussions and work (e.g. security issues). Also, some discussions may need to be confidential (e.g. HR). So, default to open, but be mindful of the exceptions.
Platforms Need to be Accessible, Rich, and Searchable
There are myriad platforms for asynchronous working. GitHub, GitLab, Slack, Mattermost, Asana, Phabricator, to name just a few.
When evaluating platforms it is key to ensure that they can be made (a) securely accessible from anywhere (e.g. desktop/mobile support, available outside the office), (b) provide a rich and efficient environment for collaboration (e.g. rich discussions with images/videos/links, project management, simple code collaboration and review), (c) and any material is easily searchable (finding previous projects/discussions to learn from them, or finding new issues to focus on).
Always Maintain History and Never Delete, but Archive
You should maintain history in everything you do. This should include discussions, work/issue tracking, code (revision control), releases, and more.
On a related note, you should never, ever permanently delete material. Instead, that material should be archived. As an example, if you file an issue for a bug or problem that is no longer pertinent, archive the issue so it doesn’t come up in popular searches, but still make it accessible.
Consolidate Identity and Authentication
Having a single identity for each employee on asynchronous infrastructure is important. We want to make it easy for people to reference individual employees, so a unique username/handle is key here. This is not just important technically, but also for building relationships – that username/handle will be a part of how people collaborate, build their reputations, and communicate.
A complex challenge with deploying asynchronous infrastructure is with identity and authentication. You may have multiple different platforms that have different accounts and authentication providers.
Where possible invest in Single Sign On and authentication. While it requires a heavier up-front lift, consolidating multiple accounts further down the line is a nightmare you want to avoid.
Validate, Incentivize, and Reward
Human beings need validation. We need to know we are on the right track, particularly when joining new teams and projects. As such, you need to ensure people can easily validate each other (e.g. likes and +1s, simple peer review processes) and encourage a culture of appreciation and thanking others (e.g. manager and leaders setting an example to always thank people for contributions).
Likewise, people often respond well to being incentivized and often enjoy the rewards of that work. Be sure to identify what a good contribution looks like (e.g. in software development, a merged pull request) and incentivize and reward great work via both baked-in features and specific campaigns.
Be Mindful of Uncertainty, so Train, Onboard, and Support
Moving to a more asynchronous way of working will cause uncertainty in some. Not only are people often reluctant to change, but operating in a very open and transparent manner can make people squeamish about looking stupid in front of their colleagues.
So, be sure to provide extensive training as part of the transition, onboard new staff members, and provide a helpdesk where people can always get help and their questions answered.
Of course, I am merely scratching the surface of how we build asynchronous workflow, but hopefully this will get your started and generate some ideas and thoughts about how you bring this to your organization.
Of course, feel free to get in touch if you want to discuss your organization’s needs in more detail. I would also love to hear additional ideas and approaches in the comments!
The challenge? Share a great community that you feel does wonderful work. The most interesting one, according to yours truly, gets the prize.
Well, I am delighted to share that Garrett Nay bags the prize for sharing the following in his comment:
I don’t know if this counts, since I don’t live in Seattle and can’t be a part of this community, but I’m in a new group in Salt Lake City that’s modeled after it. The group is Story Games Seattle: http://www.meetup.com/Story-Games-Seattle/. They get together on a weekly+ basis to play story games, which are like role-playing games but have a stronger emphasis on giving everyone at the table the power to shape the story (this short video gives a good introduction to what story games are all about, featuring members of the group:
Story games seem to scratch a creative itch that I have, but it’s usually tough to find friends who are willing to play them, so a group dedicated to them is amazing to me.
Getting started in RPGs and story games is intimidating, but this group is very welcoming to newcomers. The front page says that no experience with role-playing is required, and they insist in their FAQ that you’ll be surprised at what you’ll be able to create with these games even if you’ve never done it before. We’ve tried to take this same approach with our local group.
In addition to playing published games, they also regularly playtest games being developed by members of the group or others. As far as productivity goes, some of the best known story games have come from members of this and sister groups. A few examples I’m aware of are Microscope, Kingdom, Follow, Downfall, and Eden. I’ve personally played Microscope and can say that it is well designed and very polished, definitely a product of years of playtesting.
They’re also productive and engaging in that they keep a record on the forums of all the games they play each week, sometimes including descriptions of the stories they created and how the games went. I find this very useful because I’m always on the lookout for new story games to try out. I kind of wish I lived in Seattle and could join the story games community, but hopefully we can get our fledgling group in Salt Lake up to the standard they have set.
What struck me about this example was that it gets to the heart of what community should be and often is – providing a welcoming, supportive environment for people with like-minded ideas and interests.
While much of my work focuses on the complexities of building collaborative communities with the intricacies of how people work together, we should always remember the huge value of what I refer to as read communities where people simply get together to have fun with each other. Garrett’s example was a perfect summary of a group doing great work here.
Thanks everyone for your suggestions, congratulations to Garrett for winning the prize, and thanks to Luma for providing the prize. Garrett, your Luma will be in the mail soon!
In the eyes of some, hell finally froze over. For many though, myself included, this was not an entirely surprising move. Microsoft are becoming an increasingly active member of the open source community, and they deserve credit for this continual stream of improvements.
When I first discovered open source in 1998, the big M were painted as a bit of a villain. This accusation was largely fair. The company went to great lengths to discredit open source, including comparing Linux to a cancer, patent litigation, and campaigns formed of misinformation and FUD. This rightly left a rather sour taste in the mouths of open source supporters.
The remnants of that sour taste are still strong in some. These folks will likely never trust the Redmond mammoth, their decisions, or their intent. While I am not condoning these prior actions from the company, I would argue that the steady stream of forward progress means that…and I know this will be a tough pill to swallow for some of you…means that it is time to forgive and forget.
This forward progress is impressive. They released their version of FreeBSD for Azure. They partnered with Canonical to bring Ubuntu user-space to Windows (as well as supporting Debian on Azure and even building their own Linux distribution, the Azure Cloud Switch). They supported an open source version of .NET, known as Mono, later buying Xamarin who led this development and open sourced those components. They brought .NET core to Linux, started their own Linux certification, released a litany of projects (including Visual Studio Code) as open source, founded the Microsoft Open Technologies group, and then later merged the group into the wider organization as openness was a core part of the company.
My personal experience with them has reflected this trend. I first got to know the company back in 2001 when I spoke at a DeveloperDeveloperDeveloper day in the UK. Over the years I flew out to Redmond to provide input on initiatives such as .NET, got to know the Microsoft Open Technologies group, and most recently signed the company as a client where I am helping them to build the next generation of their MVP and RD community. Microsoft are not begrudgingly supporting open source, they are actively pursuing it.
As such, this recent announcement from the Linux Foundation wasn’t a huge surprise to me, but was an impressive formal articulation of Microsoft’s commitment to open source. Leaders at Microsoft and the Linux Foundation should be both credited with this additional important step in the right direction, not just for Microsoft, but for the wider acceptance and growth of open source and collaboration.
Work In Progress
Now, some of the critics will be reading this and will cite many examples of Microsoft still acting as the big bad wolf. You are perfectly right to do so. So, let me zone in on this.
I am not suggesting they are perfect. They aren’t. Companies are merely vessels of people, some of which will still continue to have antiquated perspectives. Microsoft will be no different here. Of course, for all the great steps forward, sometimes there will be some steps back.
What I try to focus on however is the larger story and trends. I would argue that Microsoft is trending in the right direction based on many of their recent moves, including the ones I cited above.
Let’s not forget that this is a big company to turn around. With 114,000 employees and 40+ years of cultural heritage and norms, change understandably takes time. The challenge with change is that it doesn’t just require strategic, product, and leadership focus, but the real challenge is cultural change.
Culture is something of an amorphous concept. It isn’t a specific thing you can point to. Culture is instead the aggregate of the actions and intent of the many. You can often make strategic changes that result in new products, services, and projects, but those achievements could be underpinned by a broken, divisive, and ugly culture.
As such, culture is hard to change and requires a mix of top-down leadership and bottom-up action.
From my experience of working with Microsoft, the move to a more open company is not merely based on product-based decisions, but it has percolated in the core culture of how the company operates. I have seen this in my day to day interactions with the company and with my consulting work there. I credit Satya Nadella (and likely many others) for helping to trigger these positive forward motions.
So, are they perfect? No. Are they an entirely different company? No. But are they making a concerted thoughtful effort to really understand and integrate openness into the company? I think so. Is the work complete? No. But do they deserve our support as fellow friends in the open source community? I believe so, yes.
This week I was delighted to see that we could take the wraps off a new event that I am running in conjunction with my friends at the Linux Foundation called the Community Leadership Conference. The event will be part of the Open Source Summit which was previously known as LinuxCon and I will be running it in Los Angeles from 11th – 13th Sep 2017 and Prague from 23rd – 25th Oct 2017.
Now, some of you may be wondering if this replaces or is different to the Community Leadership Summit in Portland/Austin. Let me add some clarity.
The Community Leadership Summit
The Community Leadership Summit takes place each year the weekend before OSCON. I can confirm that there will be another Community Leadership Summit in 2017 in Austin. We plan to announce this soon formally.
The Community Leadership Summit has the primary goal of bringing together community managers from around the world to discuss and debate community leadership principles. The event is an unconference and is focused on discussions as opposed to formal presentations. As such, and as with any unconference, the thrill of the event is the organic schedule and conversations that follow. Thus, CLS is a great event for those who are interested in playing an active role in furthering the art of and science of community leadership more broadly in an organic way.
The Community Leadership Conference
The Community Leadership Conference, which will be part of the Open Source Summit in Los Angeles and Prague, has a slightly different format and focus.
CLC will instead be a traditional conference. My goal here is to bring together speakers from around the world to deliver presentations, panels, and other material that shares best practices, methods, and approaches in community leadership, and specific to open source. CLC is not intended to shape the future of community leadership, but more to present best practices and principles for consumption, and tailed to the needs of open source projects and organizations.
So, in summary, the Community Leadership Conference is designed to be a place to consume community leadership best practices and principles via carefully curated presentations, panels, and networking. The Community Leadership Summit is designed to be more of an informal roll-your-sleeves up summit where attendees discuss and debate community leadership to help shape how it evolves and grows.
As regular readers will know, I am passionate about evolving the art and science of community leadership and while CLS has been an important component in this evolution, I felt we needed to augment it with CLC. These two events, combined with the respective audiences of their shared conferences, and bolstered by my wonderful friends at O’Reilly and the Linux Foundation, are going to help us to evolve this art and science faster and more efficiently than ever.
I hope to see you all at either or both of these events!
For some reason, wifi has always been the bane of my technological existence. Every house, every router, every cable provider…I have always suffered from bad wifi. I have tried to fix it and in most cases failed.
As such, I was rather excited when I discovered the Luma a little while ago. Put simply, the Luma is a wifi access point, but it comes in multiple units to provide repeaters around your home. The promise of Luma is that this makes it easier to bathe your home in fast and efficient wifi, and comes with other perks such as enhanced security, access controls and more.
So, I pre-ordered one and it arrived recently.
I rather like the Luma so I figured I would write up some thoughts. Stay tuned though, because I am also going to give one away to a lucky reader.
When it arrived I set it up and followed the configuration process. This was about as simple as you can imagine. The set came with three of these:
I plugged each one in turn and the Android app detected each one and configured it. It even recommended where in the house I should put them.
So, I plonked the different Lumas around my house and I was getting pretty reputable speeds.
Of course, the very best wifi routers blend into the background and don’t require any attention. After a few weeks of use, this has been the case with the Luma. They just sit there working and we have had great wifi across the house.
There are though some interesting features in the app that are handy to have.
Firstly, device management is simple. You can view, remove, and block Internet to different devices and even group devices by person. So, for example, if you neighbors use your Internet from time to time you can group their devices and switch them off if you need precious bandwidth.
Viewing these devices from an app and not an archaic admin panel also makes auditing devices simple. For example, I saw two weird-looking devices on our network and after some research they turned out to be Kindles. Thanks, Amazon, for not having descriptive identifiers for the devices, by the way. 😉
Another neat feature is content filtering. If you have kids and don’t want them to see some naughty content online, you can filter by device or across the whole network. You could also switch off their access when dinner is ready.
So, overall, I am pretty happy with the Luma. Great hardware, simple setup, and reliable execution.
Win a Luma
I want to say a huge thank-you to the kind folks at Luma, because they provided me with an additional Luma to give away here!
Participating is simple. As you know, my true passion in life is building powerful, connected, and productive communities. So, unsurprisingly, I have a question that relates to community:
What is the most interesting, productive, and engaging community you have ever seen?
To participate simply share your answer as a comment on this post. Be sure to tell me which community you are nomating, share pertinant links, and tell me why that community is doing great work. These don’t have to be tech communities – they can be anything, craft, arts, sports, charities, or anything else. I want you to sell me on why the community is interesting and does great work.
Please note: if you include a lot of links, or haven’t posted here before, sometimes comments get stuck in the moderation queue. Rest assured though, I am regularly reviewing the queue and your comment will appear – please don’t submit multiple comments that are the same!
The deadline for submissions is 12pm Pacific time on Fri 18th Nov 2016.
I will then pick my favorite answer and announce the winners. My decision is final and based on what I consider to be the most interesting submission, so no complaining, people. Thanks again to Luma for the kind provision of the prize!
I was really impressed with All Things Open last year and have subsequently become friends with the principle organizer, Todd Lewis. I loved how the team put together a show with the right balance of community and corporation, great content, exhibition and more.
All Thing Open 2016 is happening next week and I will be participating in a number of areas:
- I will be MCing the keynotes for the event. I am looking forward to introducing such a tremendous group of speakers.
- Jeremy King, CTO of Walmart Labs and I will be having a fireside chat. I am looking forward to delving into the work they are doing.
- I will also be participating in a panel about openness and collaboration, and delivering a talk about building a community exoskeleton.
- It is looking pretty likely I will be doing a book signing with free copies of The Art of Community to be given away thanks to my friends at O’Reilly!
The event takes place in Raleigh, and if you haven’t registered yet, do so right here!
Also, a huge thanks to Red Hat and opensource.com for flying me out. I will be joining the team for a day of meetings prior to All Things Open – looking forward to the discussions!
Here we are with another roundup of things I have been working on, complete with a juicy foray into the archives too. So, sit back, grab a cup of something delicious, and enjoy.
To gamify or not to gamify community (opensource.com)
In this piece I explore whether gamification is something we should apply to building communities. I also pull from my experience building a gamification platform for Ubuntu called Ubuntu Accomplishments.
The GitLab Master Plan
Recently I have been working with GitLab. The team has been building their vision for conversational development and I MCed their announcement of their plan. You can watch the video below for convenience:
Social Media: 10 Ways To Not Screw It Up (jonobacon.org)
Here I share 10 tips and tricks that I have learned over the years for doing social media right. This applies to tooling, content, distribution, and more. I would love to learn your tips too, so be sure to share them in the comments!
Linux, Linus, Bradley, and Open Source Protection
Recently there was something of a spat in the Linux kernel community about when is the right time to litigate companies who misuse the GPL. As a friend of both sides of the debate, this was my analysis.
The Psychology of Report/Issue Templates (jonobacon.org)
As many of you will know, I am something of a behavioral economics fan. In this piece I explore the interesting human psychology behind issue/report templates. It is subtle nudges like this that can influence the behavioral patterns you want to see.
My Reddit AMA
It would be remiss without sharing a link to my recent reddit AMA where I was asked a range of questions about community leadership, open source, and more. Thanks to all of you who joined and asked questions!
Looking For Talent
I also posted a few pieces about some companies who I am working with who want to hire smart, dedicated, and talented community leaders. If you are looking for a new role, be sure to see these:
From The Archives
My Forbes piece on the impact of behavioral economics on technologies, including an interview with Dan Ariely, TED speaker, and author of many books on the topic.
Advice for building a career in open source (opensource.com)
In this piece I share some recommendations I have developed over the years for those of you who want to build a career in open source. Of course, I would love to hear you tips and tricks too!