Tag Archives: community

Awesome Simple Open Data use case – Welcome Wagon for New Community Businesses

A few weeks ago I was at an event in Victoria, British Columbia at event where people were discussing the possibilities, challenges and risk of open data. During the conversation, one of the participants talked about how they wanted an API for business license applications from the city.

This is a pretty unusual request – people have told me about their desire for business licenses data especially at the provincial/state and national level, but also at the local level. However, they are usually happy with a data dump once a year or quarter since they generally want to analyze the data for urban planning or business planning reasons. But an API – which would mean essentially constant access to the data and the opportunity to see changes to the database in real time (e.g. if a business registered or moved) – was different.

The reason? The individual – who was an entrepreneur and part of the local Business Improvement Area – wanted to be able to offer a “welcome wagon” to other new businesses in his community. If he knew when a business opened up he could reach out and help make them welcome them to the neighborhood. He thought it was always nice when shopkeepers knew one another but didn’t always know what was going on even a few blocks away because, well, he was often manning his own shop. I thought it was a deeply fascinating example of how open data could help foster community and is something I would have never imagined.

Food for thought and wanted to share.

Community Managers: Expectations, Experience and Culture Matter

3 Replies

Here’s an awesome link to grind home my point from my OSCON keynote on Community Management, particularly the part where I spoke about the importance of managing wait times – the period between when a volunteer/contributor takes and action and when they get feedback on that action.

In my talk I referenced code review wait times. For non-developers, in open source projects, a volunteer (contributor) will often write a patch which they must be reviewed by someone who oversees the project before it gets incorporated into the software’s code base. This is akin to a quality assurance process – say, like if you are baking brownies for the church charity event, the organizer probably wants to see the brownies first, just to make sure they aren’t a disaster. The period between which you write the patch (or make the brownies) and when the project manager reviews them and say they are ok/not ok, that’s the wait time.

The thing is, if you never tell people how long they are going to have to wait – expect them to get unhappy. More importantly, if, while their waiting, other contributors come and make negative comments about their contributions, don’t be surprised if they get even more unhappy and become less and less inclined to submit patches (or brownies, or whatever makes your community go round).

In other words while your code base may be important but expectations, experience and culture matter, probably more. I don’t think anyone believes Drupal is the best CMS ever invented, but its community has a pretty good expectations, a great experience and fantastic culture, so I suspect it kicks the ass of many “technically” better CMS’s run by lesser managed communities.

Because hey, if I’ve come to expect that I have to wait an infinite or undetermined amount of time, if the experience I have interacting with others suck and if the culture of the community I’m trying to volunteer with is not positive… Guess what. I’m probably going to stop contributing.

This is not rocket science.

And you can see evidence of people who experience this frustration in places around the net. Edd Dumbill sent me this link via hacker news of a frustrated contributor tired of enduring crappy expectations, experience and culture.

Heres what happens to pull requests in my experience:

you first find something that needs fixing

you write a test to reproduce the problem

you pass the test

you push the code to github and wait

then you keep waiting

then you wait a lot longer (it’s been months now)

then some ivory tower asshole (not part of the core team) sitting in a basement finds a reason to comment in a negative way.

you respond to the comment

more people jump on the negative train and burry your honestly helpful idea in sad faces and unrelated negativity

the pull dies because you just don’t give a fuck any more

If this is what your volunteer community – be it software driven, or for poverty, or a religious org, or whatever – is like, you will bleed volunteers.

This is why I keep saying things like code review dashboards matter. I bet if this user could at least see what the average wait time is for code review he’d have been much, much happier. Even if that wait time were a month… at least he’d have known what to expect. Of course improving the experience and community culture are harder problems to solve… but they clearly would have helped as well.

Most open source projects have the data to set up such a dashboard, it is just a question of if we will.

Okay, I’m late for an appointment, but really wanted to share that link and write something about it.

NB: Apologies if you’ve already seen this. I accidentally publishes this as a page, not a post on August 24th, so it escaped most people’s view.

Social Media and Rioters

10 Replies

My friend Alexandra Samuel penned a piece titled “After a Loss in Vancouver, Troubling Signals of Citizen Surveillance” over at the Harvard Business Review. The piece highlights her concern with the number of people willing to engage in citizen surveillance.

As she states:

It’s one thing to take pictures as part of the process of telling your story, or as part of your (paid or unpaid) work as a citizen journalist. It’s another thing entirely to take and post pictures and videos with the explicit intention of identifying illegal (or potentially illegal) activity. At that moment you are no longer engaging in citizen journalism; you’re engaging in citizen surveillance.

And I don’t think we want to live in a society that turns social media into a form of crowdsourced surveillance. When social media users embrace Twitter, Facebook, YouTube and blogs as channels for curating, identifying and pursuing criminals, that is exactly what they are moving toward.

I encourage you to read the piece, and, I’m not sure I agree with much of it on two levels.

First, I want to steer away from good versus bad and right versus wrong. Social Media isn’t going to create only good outcomes, or only bad outcomes, it is going to create both (something I know Alex acknowledges). This technology will, like previous technologies, reset what normal means. In the new world we are becoming more powerful “sensors” in our society. We can enable others to know what, good and bad, is going on around us. To believe that we won’t share, and that others won’t use our shared information to inform their decisions, is simply not logical. As dBarefoot points out in the comments there are lots of social good that can come for surveillance. In the end you can’t post videos of human right injustices without also being able to post videos of people at abortion clinics, you can’t post videos of officials taking bribes without also being able to post videos of people smoking drugs at a party. The alternative, a society where people are not permitted to share, strikes me as even more dangerous than a society where we can share but where one element of that sharing ends up being used as surveillance. My suspicion is that we may end up regulating some use – there will be some things people cannot share online (visiting abortion clinics may end up being one of those) but I’m not confident of even this.

But I suspect that in a few decades my children will be stunned that I grew up in a world of no mutual surveillance. That we tolerated the risks of a world where mutual surveillance didn’t exist – they may wonder at a basic level, how we felt safe at night or in certain circumstances (I really recommend David Brin’s Science Fiction writing, especially Earth in which he explores this idea). I can also imagine they will find the idea of total anonymity and having an untraceable past to both eerie, frightening and intriguing. In their world, having grown up with social media will be different, some of the things we feel are bad, they will like, and vice versa.

Another issues missing from Alex’s piece is the role of the state. It is one thing for people to post pictures of each other, it is another about how, and if, the state does the same. As many tweeters stated – this isn’t 1994 (the last time there were riots in Vancouver). Social media is going to do is make the enforcement of law a much and the role of the state a much trickier subject. Ultimately, they cannot ignore photos of rioters engaged in illegal acts. So the question isn’t so much on what we are going to share, it is about what we should allow the state to do, and not to do, with the information we create. The state’s monopoly on violence gives it a unique role, one that will need to be managed carefully. This monopoly, combined with a world of perfect (or at least, a lot more) information will I imagine necessitate a state and justice system that that looks very, very different than the one we have right now if we are to protect of civil liberties as we presently understand them. (I suspect I’ll be writing some more about this)

But I think the place where I disagree the most with Alex is in the last paragraph:

What social media is for — or what it can be for, if we use it to its fullest potential — is to create community. And there is nothing that will erode community faster, both online and off, than creating a society of mutual surveillance.

Here, Alex confuses the society she’d like to live in with what social media enables. I see nothing to suggest that mutual surveillance will erode community, indeed, I think it already has demonstrated that it does the opposite. Mutual surveillance fosters lots of communities – from communities that track human rights abuses, to communities that track abortion providers to communities that track disabled parking violators. Surveillance builds communities, it may be that, in many cases, those communities pursue the marginalization of another community or termination of a specific behaviour, but that does not make them any less a part of our society’s fabric. It may not create communities everyone likes, but it can create community. What matters here is not if we can monitor one another, but what ends up happening with the information we generate, and why I think we’ll want to think hard about what we allow the state to do and to permit others to do, more and more carefully.

Creating effective open government portals

7 Replies

In the past few years a number of governments have launched open data portals. These sites, like www.data.gov or data.vancouver.ca share data – in machine readable formats (e.g. that you can play with on your computer) that government agencies collect.

Increasingly, people approach me and ask: what makes for a good open data portal? Great question. And now that we have a number of sites out there we are starting to learn what makes a site more or less effective. A good starting point for any of this is 8 Open Government principles, and for those newer to this discussion, there are the 3 laws of open data (also available in German Japanese, Chinese, Spanish, Dutch and Russian).

But beyond that, I think there are some pretty tactical things, data portal owners should be thinking about. So here are some issues I’ve noticed and thought might be helpful.

1. It’s all about automating the back end

Probably the single greatest mistake I’ve seen governments make is, in the rush to get some PR or meet an artificial deadline, they create a data portal in which the data must be updated manually. This means that a public servant must run around copying the data out of one system, converting (and possibly scrubbing it of personal and security information) and then posting it to the data portal.

There are a few interrelated problems with this approach. Yes, it allows you to get a site up quickly but… it isn’t sustainable. Most government IT departments don’t have a spare body that can do this work part time, even less so if the data site were to grow to include 100s or 1000s of data sets.

Consequently, this approach is likely to generate ill-will towards the government, especially from the very community of people who could and should be your largest supporters: local tech advocates and developers.

Consider New York, here is a site where – from I can tell – the data is not regularly updated and grumblings are getting louder. I’ve heard similar grumblings out of some developers and citizens in Canadians cities where open data portals get trumpeted despite infrequent updates and having few data sets available.

If you are going to launch an open data portal, make sure you’ve figured out how to automate the data updates first. It is harder to do, but essential. In the early days open data sites often live and die based on the engagement of a relatively small community or early adopters – the people who will initially make the data come alive and build broader awareness. Frustrate the community and the initiative will have a harder time gaining traction.

2. Keep the barriers low

Both the 8 principles and 3 laws talk a lot about licensing. Obviously there are those who would like the licenses on many existing portals to be more open, but in most cases the licenses are pretty good.

What you shouldn’t do is require users to register. If the data is open, you don’t care who is using it and indeed, as a government, you don’t want the hassle of tracking them. Also, don’t call your data open if members must belong to a educational institution or a non-profit. That is by definition not data that is open (I’m looking at you StatsCan, its not liberated data if only a handful of people can look at it, sadly, you’re not the only site to do this). Worst is one website that, in order to access the online catalogue you have to fax in a form outlining who you are.

This is the antithesis of how an open data portal should work.

3. Think like (or get help from) good librarians and designers

The real problem is when sites demand too much of users to even gain access to the data. Readers of this blog know about my feelings regarding Statistics Canada’s website, the data always seems to be one click away. Of course, that’s if you even think you are able to locate the data you are interested in, which usually seems impossible to find.

And yes, I know that Statistics Canada’s phone operators are very helpful and can help you locate datasets quickly – but I submit to you that this is a symptom of a problem. If every time I went to Amazon.com I had to call a help desk to find the book I was interested in I don’t think we’d be talking about how great Amazon’s help desk was. We’d be talking about how crappy their website is.

The point here is that an open data site is likely to grow. Indeed, looking at data.gov and data.gov.uk these sites now have thousands of data sets on them. In order to be navigable they need to have excellent design. More importantly, you need to have a new breed of librarian – one capable of thinking in the online space – to help create a system where data sets can be easily and quickly located.

This is rarely a problem early on (Vancouver has 140 data sets up, Washington DC, around 250, these can still be trolled through without a sophisticated system). But you may want to sit down with a designer and a librarian during these early stages to think about how the site might evolve so that you don’t create problems in the future.

4. Feedback

Finally, I think good open data portals want, and even encourage feedback. I like that data.vancouver.ca has a survey on the site which asks people what data sets they would be interested in seeing made open.

But more importantly, this is an area where governments can benefit. No data set is perfect. Most have a typo here or there. Once people start using your data they are going to find mistakes.

The best approach is not to pretend like the information is perfect (it isn’t, and the public will have less confidence in you if you pretend this is true). Instead, ask to be notified about errors. Remember, you are using this data internally, so any errors are negatively impacting your own planning and analysis. By harnessing the eyes of the public you will be able to identify and fix problems more quickly.

And, while I’m sure we all agree this is probably not the case, maybe the face that the data us public, there will be a small added incentive to fixing it quickly. Maybe.

How Science Is Rediscovering "Open" And What It Means For Government

4 Replies

Pretty much everybody in government should read this fantastic New York Times article Sharing of Data Leads to Progress on Alzheimer’s. On one hand the article is a window into what has gone wrong with science – about how all to frequently a process that used to be competitive but open, and problem focused has become a competitive but closed and intellectual property driven (one need only look at scientific journals to see how slow and challenging the process has become).

But strip away the talk about the challenges and opportunities for science. At its core, this is an article is about something more basic and universal. This is an article about open data.

Viewed through this lens it is a powerful case study for all of us. It is a story of how one scientific community’s (re)discovery of open principles can yield powerful lessons and analogies for the private sector and, more importantly the public sector.

Consider first, the similarities in problems. From the article:

Dr. Potter had recently left the National Institutes of Health and he had been thinking about how to speed the glacial progress of Alzheimer’s drug research.

“We wanted to get out of what I called 19th-century drug development — give a drug and hope it does something,” Dr. Potter recalled in an interview on Thursday. “What was needed was to find some way of seeing what was happening in the brain as Alzheimer’s progressed and asking if experimental drugs could alter that progression.”

Our government’s are struggling too. They are caught with a 20th-century organizational, decision-making and accountability structures. More to the point, they move at a glacial speed. On the one hand we should be worried about a government that moves too quickly, but a government that is too slow to be responsive to crises or to address structural problems is one that will lose the confidence of the public. Moreover, like in healthcare, many of the simpler problems have been addressed. citizens are looking for solutions to more complex problems. As with the scientists and Alzheimer’s we may need new models to speed the process up for understanding and testing solutions for these issues.

To overcome this 19th century approach – and achieve the success they currently enjoy – the scientists decided to do some radical.

The key to the Alzheimer’s project was an agreement as ambitious as its goal: not just to raise money, not just to do research on a vast scale, but also to share all the data, making every single finding public immediately, available to anyone with a computer anywhere in the world.

No one would own the data. No one could submit patent applications, though private companies would ultimately profit from any drugs or imaging tests developed as a result of the effort.

Consider this. Here a group of private sector companies recognize the intellectual property slows down innovation. The solution – dilute the intellectual property, focus on sharing data and knowledge, and understand that those who contribute most will be best positioned to capitalize on the gains at the end.

Sadly this is the same problem faced within governments. Sometimes it has to do with actual intellectual property (something I’ve recently argued our governments should abandon). However, the real challenge isn’t about about formal rules, it is more subtle. In complex siloed organizations where knowledge is power the incentives to maximize influence are to not share knowledge and data. Better to use the information you have strategically, in a limited fashion, to maximize influence. The result, data is kept as a scarce, but strategic asset. This is a theme I tackled both in my chapter in Open Government and in blog posts like this one.

In short, the real challenge is structural and cultural. Scientists had previously existed in a system where reputation (and career advancement) was built by hoarding data and publishing papers. While the individual incentives were okay, collectively this behavior was a disaster. The problem was not getting solved.

Today, it would appear that publishing is still important, but there are reputational effects from being the person or group to share data. Open data is itself a currency. This is hardly surprising. If you are sharing data it means you are doing lots of work, which means you are likely knowledgeable. As a result, those with a great deal of experience are respected but there remains the opportunity for those with radical ideas and new perspectives to test hypothesis and gain credibility by using the open data.

Unsurprisingly, this shift wasn’t easy:

At first, the collaboration struck many scientists as worrisome — they would be giving up ownership of data, and anyone could use it, publish papers, maybe even misinterpret it and publish information that was wrong.

Wow, does that sound familiar. This is invariably the first question government officials ask when you begin talking about open data. The answer, both in the scientific community and for government, is that you either believe in the peer-review process and public debate, or you don’t. Yes, people might misrepresent the data, or publish something that is wrong, but the bigger and more vibrant the community, the more likely people will find and point out the errors quickly. This is what innovation looks like… people try out ideas, sometimes they are right, sometimes they are wrong. But the more data you make available to people the more ideas can be tested and so the faster the cycle of innovation can proceed.

Whether it is behind the firewall or open to the public, open data is the core to accelerating the spread of ideas and the speed of innovation. These scientists are rediscovering that fact as our some governments. We’ve much to learn and do, but the case is becoming stronger and stronger that this is the right thing to do.

Some thoughts on improving Bugzilla

60 Replies

One of the keys to making an open source project work is getting feedback from users and developers about problems (bugs) in the code or system. Mozilla (the organization behind Firefox and Thunderbird) uses Bugzilla, but organizations have developed a variety of systems for dealing with this issue. For example, many cities use 311. I’m going to talk about Bugzilla and Mozilla in this case, but I think the lessons can be applied more broadly for some of my policy geek friends.

So first, some first principles. Why does getting the system right matter? A few reasons come to mind:

Engagement: For many people Bugzilla is their first contact with “the community.” We should want users to have a good experience so they feel some affinity towards us and we should want developers to have a great experience so that they want to deepen their level of participation and engagement.
Efficiency: If you have the wrong or incomplete information it is hard (or impossible) to solve a problem, wasting the precious time of volunteer contributors.

I also concede that these two objectives may not always be congruent. Indeed, at times there may be trade offs between them… but I think there is a lot that can be done to improve both.

I’ve probably got more ideas than can fit (or should fit) into one post so I’m going to unload a few. I’ve got more that relate to the negotiation and empathetic approaches I talked about at the Mozilla Summit.

One additional thought. Please feel free to dump all over these. Some changes many not be as simple as I’ve assumed. Others may break or contravene important features I’m not aware of. Happy to engage people on these, please do not see them as an end point, but rather a beginning. My main goal with this first batch of suggestions was to find things that felt easier to do and so could be implemented quickly if there was interest and would help reduce transactions costs right away.

1. Simplifying Menus

First. I thought there were some simple changes that could render the interface cleaner and friendlier. It’s pretty text heavy – which is great for advanced users, but less inviting for newer users. More importantly however, we could streamline things to make it easier for people to onboard.

Take for example, the landing page of Bugzilla. It is unclear to me why “Open a new Account” should be on this page. Advanced users will know they want to file a bug, novices (who may be on the wrong site and who should be looking for support) might believe they have to open and account to get support. So why not eliminate the option altogether. You are going to get it anyways if you click on “File a bug.”

Current

Proposed

In addition, I got rid of the bottom menu bar (which I don’t think is necessary on this screenƒclu given all the features were along the top as well). I also ditched the Release Notes and User Guide for Bugzilla as I had doubts about whether users were, at this point and on this screen, looking for those things)

2. Gather more information about our users (and, while I’m at it, some more simplifying)

Once you choose to file a bug you get prompted to either log in or create an account. At this point, if you want to create an account. I thought this page was hard to read with the text spanning the whole width, plus, there is some good info we could gather about users at this point (the point it feels they are mostly likely going to add to their profile).

Current

Proposed

Couple things a like about this proposed screen.

One, if you are a lost user just looking for support we likely snag you before you fill out a bugzilla account. My feeling is the bugzilla is a scary place that most users shouldn’t end up in… we need to give people lots of opportunities to opt for support before diving in, in case that is what they really need.

Second, in this proposed version we tell people to read the bugzilla guidelines and suggest using an alternate email before they punch their email into the email field box.

In addition, we ask the user for their real name now (as opposed to relying on them to fill it out later). This nudge feels important as the more people with real names on the site, the more I think people will develop relationships with one another. Finally we ask people if English is their second language and if this is their first open source project.

Finally, with the extra data fields we can help flag users as ESL or new and thus in need of more care, patience and help as they on-ramp (see screen shots below). We could even modify the Bugzilla guidelines to inform people to provide newbies and ESL’s with appropriate respect and support.

Current

Proposed

I imagine that your “newbie” status would disappear either when you want (some sort of preference in your profile) or after you’ve engaged in a certain amount of activity.

3. Make life easier for users and the triage guys

Here is an idea I had talking with some of the triage guys at the Mozilla Summit.

Let’s suppose that someone submits a bug that isn’t really a bug but a support issue. I’m informed that this happens with a high degree of frequency. Would it be nice if, with a click of a mouse, the triage guys could move that bug out of Bugzilla and into a separate database (ideally this would be straight into SUMO, but I respect that this might not be easy – so just moving it to a separate database and de-cluttering bugzilla would be a great first start – the SUMO guys could then create a way to import it). My sense is that this simply requires creating a new resolution field – I’ve opted to call it “Support” but am happy to name it something else.

Current

Proposed

This feels like a simple fix and it would quickly move a lot of bugs that are cluttering up bugzilla… out. This is important as searches for bugs often return many results that are support oriented, making it harder to find the bugs you are actually searching for. Better still, it would get them somewhere where they could more likely help users (who are probably waiting for us to respond).

Of course, presently bugzilla will auto generate an email that looks like the first one and this isn’t going to help. So what if we did something else?

Current

Proposed

Here is the auto-generated email I think we should be sending users whos bugs get sent to SUMO. I’ve proposed a few things.

First, if these are users who’ve submitted inappropriate bugs and who really need support, giving them a bugzilla email isn’t going to help them, they aren’t even going to know how to read it.

Second, there is an opportunity to explain to them where they should go for help – I haven’t done that explicitly enough in this email – but you get the idea

Third, when the bug gets moved to SUMO it might be possible to do a simple key word analysis of the bug and, from that, determine what are the most likely support articles they are looking for. Why don’t we send them the top 3 or 5 as hyperlinks in the email?

Fourth, if this really is a bug from a more sophisticated user, we give them a hyperlink back to bugzilla so they can make a note or comment.

What I like about this is it is customized engagement at a low cost. More importantly, it helps unclutter things while also making us more responsive and creating a better experience for users.

4. Make Bugzilla Celebrate, enhance our brand and build community

Okay, so here’s the thing that really bugs me about bugzilla. If we want to be onramping people and building community, shouldn’t we celebrate people’s successes? At the moment this is the email you get from Bugzilla when a bug you’ve submitted gets patched:

BORING! Here, at the moment of maximum joy, especially for casual or new bugzilla participants we do nothing to engage or celebrate.

This, is what I think the auto-generated bugzilla email should look like.

Yes, I agree that hard core community members probably won’t care about these types of bugs, but for more casual participants this is an opportunity to explain how open source and mozilla works (the graphic) as well as a chance to educate them. I’ve even been more explicit about this by offering links to a) explain the open web, b) learn about mozilla and open source; and c) donate to the foundation (given this is a moment of pride for many non-developer end users)

Again, I’m not overly attached to this design per se, it would just be nice to have something fun, celebratory and mozillaesque.

Okay, it is super late and I’m on an early flight tomorrow. Would love feedback on all or any of this for those who’ve made it this far. I’ll be sharing more thoughts, especially on empathetic nudges and community management in bugzilla ASAP.

Connectedness, Volleyball and Online Communities

4 Replies

I’m currently knee deep into Connected: The Surprising Power of Our Social Networks and How They Shape Our Lives by Christakis & Fowler and am thoroughly enjoying it.

One fascinating phenomenon the book explores is how emotions can spread from person to person. In other words, when you are happy you increase the odds your friends will be happy and, interestingly, that your friends’ friends will be happy. Indeed Christakis & Fowler’s research suggests that emotional states are, to a limited degree, contagious.

All this reminded me of playing competitive volleyball. I’ve always felt volleyball is one of the most psychologically difficult games to play. I’ve regularly seen fantastic teams collapse in front of vastly inferior opponents. I used to believe that the unique structure of volleyball accounted for this. The challenge is that the game pauses at the end of every point, allowing players to reflect on what happened and, more importantly, assign blame (which can often be allocated to a single individual on the team). This makes it easy for teams to start blaming a player, over-think a point, or get frustrated with one another.

As a result, even prior to reading Connected, I knew team cohesion was essential in volleyball (and, admittedly, any sport) . This is often why, between points, you’ll see volleyball teams come together and high-five or shake hands even if they lost the point. If emotions and confidence are contagious, I can now see why it is a team starts to lose a little confidence and consequently then plays a little worse causing them to lose still more confidence and then, suddenly they are in a negative rut and can’t escape.(Indeed, this peer reviewed paper showed that tactile touch among NBA players was a predictor of individual and team success)

Of course, I’ve also long believed the same is true of online (and, in particular, open source) communities. That poisonous and difficult people don’t just negatively impact the people they are in direct contact with, but also a broader group of people in the community. Moreover, because communication often takes place in comment threads the negative impact of poisonous people could potentially linger, dragging down the attitude and confidence of everyone else in the community. I’ve often thought that the consequence of negative behaviours in the online communities has been underestimated – Christakis and Fowler’s research suggests there are some more concrete ways to measure this negative impact, and to track it. Negative behaviour fosters (and possibly even attracts) still more negative behaviour, creating a downward loop and likely causing positive or constructive people to opt out, or even never join the community in the first place.

In the end, finding ways to identify, track and mitigating negative behaviour early on – before it becomes contagious – is probably highly important. This is just an issue of having people be positive, it is about creating a productive and effective space, be it in pursuit of an open source software product, or a vibrant and interesting discussion at the end of an online newspaper article.

Open Source Strategy: OpenMRS case study

4 Replies

Last week I had the pleasure of being invited to Indianapolis to give a talk at the Regenstrief Institute – an informatics and healthcare research organization – which also happens to host the founders of OpenMRS.

For those not familiar with OpenMRS (which I assume to be most of you) it is open-source, enterprise electronic medical record system platform specifically designed to respond to those actively building and managing health systems in the developing world. It’s a project I’m endlessly excited about not only because of its potential to improve healthcare in developing and emerging markets, but also because of its longer-term potential to serve as a disruptive innovator in developed markets.

Having spent a few days at Regenstrief hanging out with the OpenMRS team, here are some take aways I have regarding where they are, and where – in my mind – they should consider heading and what are some of the key places they could focus on to get there.

Current State: Exiting Stealth Mode

Paul Biondich and Andrew Arenson point me to this article about Community Source vs. Open Source which has an interesting piece on open source projects that operate in “Stealth Mode”

It is possible to find models similar to community source within the open source environment. For example, some projects opt to launch in a so called ‘stealth mode’, that is, they operate as a truly open source development from inception, but restrict marketing information about the project during the early stages. This has the effect of permitting access to anyone who cares enough to discover the project, whilst at the same time allowing the initiating members to maintain a focus on early strategic objectives, rather than community development.

OpenMRS has grown in leaps and bounds and – I would argue – has managed to stay in stealth mode (even with the help of their friends at Google summer of code). But for OpenMRS to succeed it must exit stealth mode (a transition that has already been steadily gathering steam). By being more public it can attract more resources, access a broader development community and role out more implementations for patients around the world. But to succeed I suspect that a few things need to be in place.

Core Opportunities/Challenges:

1. Develop OpenMRS as a platform to push people towards cooperating (as opposed requiring collaboration) whenever possible.

One of the smartest things Firefox did was create add-ons. The innovation of add-ons accomplished two benefits. First, it allowed those working on the trunk of the Firefox code to continue to do their work without being distracted by as many feature requests from developers who had an idea they wanted to try out. Second, it increased the number of people who could take interest in Firefox, since now you could code up your own add-on cooperatively but independently, of the rest of the project.

With OpenMRS my sense is that then entire UI is a platform that others should be able to develop or build add-on’s for. Indeed, the longer term business model that makes significant sense to me is to treat OpenMRS like WordPress or Drupal. The underlying code is managed by a core open source community but installation, customization, skinning, widgets, etc… is done by a mix of actors from amateurs, to independent hackers and freelancers to larger design/dev organizations. The local business opportunities to support OpenMRS and, in short, create an IT industry in the developing world, are enormous.

2. Structural Change(s)

One consequence of treating OpenMRS as a platform is that the project needs to be very clear about what is “core” versus what is platform. My sense is that members of the Mozilla team does not spend a lot of time hacking on add-ons (unless they have proven so instrumental they are brought into the trunk). Looking at WordPress the standard install theme is about as basic as one could expect. It would seem no one at WordPress is wasting cycles developing nice themes to roll out with the software. There is a separate (thriving) community that can do that.

As a result, my sense is that OpenMRS should ensure that its front-end developers slowly begin to operate as a separate entity. One reason for this is that if they are too close to the trunk developers they may inadvertently prevent prevent the emergence of a community that would specialize in the installing and customizing of OpenMRS. More importantly, those working on the platform and those working on the trunk may have different interests, and so allowing that tension to emerge and learning how to manage it in the open will be healthy for the long term viability of the project as more and more people do front end work and share their concerns with trunk developers.

3. Stay Flexible by Engaging in Community Management/Engagement

One of the challenges that quickly emerges when one turns a software product into an innovation platform is that the interests of those working on the product and those developing on the platform can quickly divide. One often here’s rumblings from the Drupal community about how drupal core developers often appear more interested in writing interesting/beautiful code than in making Drupal easier to use for businesses (core vs. platform!). Likewise, Firefox and Thunderbird also hear similar rumblings from add-on developers who worry about how new platforms (jetpack) might make old platforms (add-ons) obsolete. In a sense, people who build on platforms are inherently conservative. Change, even (or sometimes especially!) change that lowers barriers to entry means more work for them. They have to ensure that whatever they’ve built on top of the platform doesn’t break when the platform changes. Conversely trunk developers can become enamored with change for change’s sake – including features that offer marginal benefits but that disrupt huge ecosystems.

In my mind, managing these types of tension is essential for an open source project – particularly one involving medical records. Trunk developers will need to have A-level facilitation and engagement skills, capable of listening to platform developers and others, not be reactive or defensive, understand interests and work hard to mediate disputes – even disputes they are involved in. These inter-personal skills will be the grease that ensure the OpenMRS machine can keep innovating while understanding and serving the developer community that is building on top of it. The OpenMRS leadership will also have to take a strong lead in this area – setting expectations around how, and how quickly OpenMRS will evolve so that the developer ecosystem can plan accordingly. Clear expectations will do wonders for reducing tensions between disparate stakeholders.

4) Set the Culture in Place now

Given that OpenMRS is still emerging from Stealth mode, now is the time to imprint the culture with the DNA it will need to survive the coming growth. A clear social contract for participation, a code of community conduct and clearer mission statement that can be referenced during decisions will all be essential. I’m of course also interested in the tools we can role out that will help manage the community. Porting over to Trac the next generation of Diederik’s bug-fix predicter, along with his flame monitor, are ways to give community the influence to have a check on poor behaviour and nudge people towards making better choices in resolving disputes.

5) Create and Share Data to Foster Markets

Finally, I think there is enormous opportunity for a IT industry – primarily located in the developing world – to emerge and support OpenMRS. My sense is that OpenMRS should do everything it can to encourage and foster such an industry.

Some ideas for doing this have been inspired by my work around open data. I think it is critical that OpenMRS start asking implementations to ping them once complete – and again whenever an upgrade is complete. This type of market data – anatomized – could help the demonstrate demand for services that already exists, as well as its rate of growth. Developers in underserved counties might realize there are market niches to be filled. In addition, I suspect that all of the OpenMRS implementations that have been completed that we don’t know about represent a huge wealth of information. These are people who managed to install OpenMRS with no support and possibly – on the cheap. Understanding how they did and who was involved could yield important best practices as well as introduce us to prospective community members with a “can do” spirit and serious skills. I won’t dive into too much detail here, but needless to say, I think anonymized but aggregated data provided for free by OpenMRS could spur further innovation and market growth.

Postscript

I’m sure there is lots to debate in the above text – I may have made some faulty assumptions along the way – so this should not be read as final or authoritative, mostly a contribution to what is an ongoing discussion at OpenMRS. Mostly I’m excited about where things are and where they are going, and the tremendous potential of OpenMRS.

Eaves.ca blogging moment #10 (2009 Edition): The CPSR Rat Pack

2 Replies

Back in 2007 I published a list of top ten blogging moments – times I felt blogging resulted in something fun or interesting. I got numerous notes from friends who found it fun to read (though some were not fans) so I’m giving it another go. Even without these moments it has been rewarding, but it is nice to reflect on them to understand why spending so many hours, often late at night, trying to post 4 times a week can give you something back that no paycheck can offer. Moreover, this is a chance to celebrate some good fortune and link to people who’ve made this project a little more fun. So here we go…

#10 Finding the Canadian Public Service Sector Renewal Rat Pack

Through blogging and twitter I discovered a community of public service sector renewal geeks who are equally driven by passion and a belief in the importance of a vibrant, successful and modern public service.

I’ve met some of this crew in the flesh, others I know only through email, comments, reading their blogs or twitter. But whether I’ve met them or not they have been a real community – a group of people with whom I can bounce ideas off of and explore new thoughts. More importantly, we support one another.

Without my blog, I’m not sure I’d have found them or them me.

So three cheers to the Rat Pack of Public Service Sector Renewal. Everyone should be so lucky as to find peers like these.

Some of the Rat Pack members include: Nick Charney, Etienne Laliberte, Peter Cowan, Thomas Kearney, Laura Wesley, Chelsea Edgell, David Hume, Doug Bastien, Tariq Piracha, Jeff Braybrook, Richard Smith, Stephanie Hayes and Bowen Moren.

eaves.ca

if writing is a muscle, this is my gym

Tag Archives: community

Awesome Simple Open Data use case – Welcome Wagon for New Community Businesses

Community Managers: Expectations, Experience and Culture Matter

Creating effective open government portals

1. It’s all about automating the back end

2. Keep the barriers low

3. Think like (or get help from) good librarians and designers

4. Feedback

How Science Is Rediscovering "Open" And What It Means For Government

Some thoughts on improving Bugzilla

Connectedness, Volleyball and Online Communities

Eaves.ca blogging moment #10 (2009 Edition): The CPSR Rat Pack