September 22, 2011
community, freesoftware, marketing, work
Comments Off
Tomorrow, Friday September 23rd, the Humanitarian FOSS track at the Open World Forum will bring together leaders from some of the most important humanitarian software projects and case studies of the impact these projects are having on people’s lives around the world. I’m happy to have been allowed to chair the track, and I am humbled by the quality of the presenters and the impact that their work is having.
In addition to the Humanitarian track, we are also honoured to have Laura Walker Hudson from FrontlineSMS give a keynote presentation on the overarching theme of “Humanitarian FOSS – serving humanity” in the main auditorium at 17:15. Laura will give an overview of the myriad ways that free and open source software is saving and helping people’s lives.
The Humanitarian track will have two core themes:
- Crisis Management– how Free and Open Source Software plays a role in extreme events
- The Sahana project, born in Sri Lanka after the 2004 tsunami in the Indian Ocean, helps NGOs and citizens caught in a crisis by crowd-sourcing missing persons reports, co-ordinate different NGOs working in the same place, and track incident reports and volunteer co-ordination.
- Tashiro Shuichi from Japan will present the ways that Open Source software helped during the tsunami disaster in Japan.
- Syrine Tlili from the Tunisian Ministry of Communication Technologies will tell us how Open Source was used by citizens during the Arab Spring revolutions
- Sigmah is a project that enables project management for NGOs
- Sustainable Development– once the crisis is over, what are the projects that help with systemic problems like education, health-care, sanitation, and documenting human rights violations?
- SMS is the killer app for communication in the developing world. Most villages in Africa, Asia and South America have cellphone connectivity, but unreliable power grid, Internet and no phone lines. FrontlineSMS enables you to send and receive SMS messages from any computer, using a cheap phone or GSM modem. It is at the heart of every prominent humanitarian software project.
- Sugar is an operating system which was designed from the ground up to meet the needs of educators in developing countries, as part of the OLPC (One Laptop Per Child) project to revolutionize the use of technology in education. Sean Daly from the Sugar project will show us a deployment of Sugar and OLPC in a secondary school in a small town in Madagascar.
- Martus, a project created by Benetech, allows the secure recording and storage of testimony relating to human rights violations. Testimony collected with Martus has been used to successfully prosecute police officers for murder in Guatemala.
- Mifos, which was developed by Grameen Bank, the pre-cursor of micro-financing, provides a micro-financing platform for financial institutions.
- Akvo help connect doers and donors to transform communities in some of the poorest parts of the world, funding water, sanitation, and health-care projects around the world.
- The Open Bank Project promotes financial transparency and provides tools to allow people to fight corruption in banking.
Coders for Social Good
There are dozens of amazing Free/Open Source Software projects working to improve the lives of people around the world. For example, Literacy Bridge provides talking books to communities in Africa, and OpenMRS enables the gathering of medical information from regional clinics to reduce child mortality by improving resource allocation.
Many Open Source developers are developing software in communities because they want to make the world a better place. Working on a humanitarian project provides a unique opportunity to combine the social good of Open Source community projects and the public good of helping people in need. Social Coding 4 Good is a new initiative from Benetech which puts willing volunteers in contact with humanitarian projects in need of resources.
The schedule for the track is available on the Open World Forum website. For any press or interview requests, please contact me by email dave@neary-consulting.com or my cellphone +33 6 77 01 92 13.
March 18, 2011
freesoftware, marketing
2 Comments
One of the things which is often lamented in free software projects is our marketing and press relations. While it’s important to avoid unfair generalisations, we have traditionally been reactive, not proactive, in dealing with the press.
A few months ago, I was talking to Jennifer Cloer, the Linux Foundation’s Director of Communications, and I asked her if she’d ever considered running a media training session for free software developers, which would help us improve the situation. She was very enthusiastic about it, and we quickly agreed that the Linux Foundation Collaboration Summit would be a great opportunity to make it happen. We made contact with Amanda McPherson, who thought it was a good idea, and the deal was done. On Thursday April 7th, we will run a 4 hour session aimed at giving participants knowledge and tools to deal more effectively with the press.
Among the topics which Jennifer will cover are:
- Building your story
- Communications “channels” and when & how to use them
- Media Training 101
- Role-Playing Media Interviews
- Social Media 101
- Q&A: Upcoming opportunities for your project
As a communications professional with lots of experience, Jennifer is really well placed to give this training. I’m personally looking forward to it, and would recommend any free software marketing people to attend. Space is limited, but open to all Summit attendees. If you do plan to attend, I’d appreciate you letting me know, so that we have an idea of the numbers we can expect.
February 3, 2010
freesoftware, gnome, marketing
2 Comments
More and more we’re seeing organisations outside the free software world try to learn the lessons of our success, and integrate “open source” practices into their organisation.
Whether it’s companies adopting transparency and other cluetrain or pinko marketing strategies, proprietary software development companies integrating standard free software practices, or one of the other areas where “crowdsourcing” has become the cool new thing, it’s obvious hat we have gotten some things right, some of the time, and it is definitely worth learning the right lessons from projects like Linux, Mozilla, GNOME, or Wikipedia, and trying to reproduce the magic elsewhere.
Sometimes this feels like the cargo cults in the Pacific Islands, trying to make airplanes land as their ancestors saw 60 years ago, by building airstrips and imitation airplanes. But at least they’re trying to figure out what makes our communities successful.
But are we learning enough lessons from others? It seems to me like we’re charging head first like sharecroppers into undiscovered country, only to find that we’ve run into a highly advanced civilisation.
As developers, we’ve invented our own brand of everything, from scratch. We figure out how to run conferences, or raise money from people who like what we do, when these are not new problems.
This isn’t new in IT. The entire learned history of typography got thrown out the window more or less, because with the advent of WYSIWYG editors and the web, everyone has complete control of their authoring tools and Comic Sans is shipped by default, and if I need to reduce the margins to get the letter to fit on one page then by golly I will.
Merchandising and recruitment of new star talent are more examples of things that some other organisations are pretty good at.
So – as an open question – are we learning the lessons from the past which we should be learning, or is it too attractive to think that what we’re doing is so new that every problem we encounter needs a new solution?
One example of a place where there is a wealth of experience out there is convincing people to give money to a cause they believe in. There are dozens of organisations that do this well – humanitarian organisations, political lobbyists, political parties, universities – the list goes on.
Can we figure out how GNOME is like them, and learn the lessons from their fundraising campaigns?
A typical fundraising drive for an organisation like this has three main steps:
- Get a list of potential donors
- Convince them that you are doing good
- Find a pressure point or argument which will convince them to donate
If you look at a mailing for Médecins Sans Frontières for example, you see all of these points in action. Find potential donors – through sign-up campaigns, former donor drives, referrals. Send them a mail package, with a newsletter outlining good work, but with just enough bad news (new conflicts, new refugees, unfinished projects) and artwork (a smiling nurse taking care of a village vs a child ill from a curable illness) to show that money given to MSF will do good, and the need has never been greater.
Your response rate may be small – perhaps only 1% – but that’s enough.
Whether we’re talking about lobby groups, political parties or humanitarian agencies, the same strategies come into play – construct big databases of potential donors, and get them riled up about the thing they’re passionate about being endangered – show them the shining light of all the good work your organisation does, and then drive the sale home by making it really easy to give money or sign up.
University fundraising is an interesting case – and in fact, GNOME’s fundraising model ressembles it now. Your primary source of donations is alumni, people who have been through the university, like receiving updates every year, maybe a class-mate just became a professor, maybe a friend’s daughter got a prize in the annual awards ceremony, maybe a club or association you were in had a good year? And then you leverage the affection with the flip side of the coin – the need, the things we’d like to do better, the project we’re fundraising for which will allow us to do great work.
All of these organisations invest heavily in direct mailing, in building and maintaining databases of supporters, and in monetising them. I recently read a book by a direct mailing copywriter called “My First 40 Years in Junk Mail” and it opened my eyes to what works in that world – and also gave some ideas on the kinds of strategies maybe the GNOME Foundation should be adopting.
The first step is building and maintaining a list of GNOME fans and supporters, by any means possible, and ensuring that they are made aware of what we’re up to and what we’d like to do. And, of course, continuing to build great products.
February 12, 2009
freesoftware, marketing, work
2 Comments
In gathering material for my series on migrating to free software, one thing immediately jumps out at me.
If your server software uses industry standard protocols to communicate with your client software, then finding free replacement software is easy, painless and transparent for the user. Need a DNS service? Bind’ll do, thank you very much. SMTP? You’re spoiled for choice – there’s Qmail, Postfix, sendmail among others. IMAP, POP3 – try Dovecot, or the UWash IMAP server. SSH – OpenSSH. FTP – PureFTPd, VSFTPd, proftpd are all fine. HTTP – Apache os one of many web servers available.
Pretty much anything with an RFC has free software implementations that are complete, and compare well with commercial competitors. Often, as is the case of Bind or Apache, they are the leaders in their space.
In other words, by using only standard client-server protocols, you have freedom to leave.
However, if your server software “integrates” tightly with your client software, in the style of Notes and Domino from Lotus/IBM, or Exchange Server and Outlook, or Sharepoint and Office, or if it has its own proprietary wire protocol, then you may have a pain point.
So the first lesson, I think, is consider how replacable server elements of your infrastructure are at the acquisition, if you want to avoid lock-in later on. As hard as projects like Samba and Zimbra chase the tail-lights of proprietary wire protocols, the easiest way to avoid them is to rely, where possible, of standard, open protocols.
And that’s what I’m looking for more than anything. How do people get around their pain points? Have people had an Exchange or Sharepoint hang-over? Now that PostPath has gone away, are people looking to get rid of Exchange stuck with Zimbra? Has migrating from MS SQL to a free database server been a pain in the leg? What have people used to centralise authentication and share home directories across the network? Is Samba with LDAP a drop-in solution?
January 23, 2009
community, freesoftware, gnome, marketing
10 Comments
Bamboozled.
That’s what I am. Bamboozled.
For those who haven’t heard this story over the last week, a young woman in Wisconsin accidentally ordered an Ubuntu laptop from Dell and dropped some college classes because she couldn’t make her internet connection work, because when she put in the CD it didn’t launch, and she didn’t have Microsoft Office, which was a requirement for her online classes.
The story, for me, is the total ignorance that both the university and the ISP have of other operating systems. Instruction manuals have information for Windows, maybe Mac, and outside of that, you’re on your own. A newcomer to Linux can’t get by on their own.
Course requirements list specific commercial programs you need to have. And we have a long hard battle to fight for minds & hearts of the universities, hardware manufacturers, ISPs and everyone else who gives software to users, or who exchange files.
The news station story had a happy ending:
However, we think we’ve helped her get back to school.
Verizon says it will dispatch a technician to try to assist her accessing the internet without using the Windows-only installation disk. Verizon says its high-speed internet does indeed support Ubuntu, but some advanced features and installation disks clearly don’t work with Linux.
MATC also says it promises to accept any of Schubert’s papers or class documents using whatever software she has installed.
Schubert’s computer came with Open Office, a word processing software package that is compatible with Microsoft Word. She says she wasn’t aware it was compatible. MATC promised to show her how to save documents in compatible formats so she could enroll in online courses again.
So – happy ending, right? We’re helping win the hearts and minds, we’ve solved a new user’s problems, and we’ve got some nice press showing how Linux users are neglected by the industry.
Ummm… no. That’s what has me bamboozled.
The story quickly got spun as “news channel said Ubuntu sucks” on tech blogs looking for a big headline. And from there, all of a sudden, the reaction of “Ubuntu fans” becomes the story. The young woman in question got some abuse for not figuring out how to solve her problems – she was “lazy”, “a dumb girl”. The news channel gets lambasted for “unscrupulous reporting”.
We all get lumped in the same bucket. When I go to free software conferences and say I work with GNOME, I hear stories about rude behaviour of others in the GNOME community. Outside the free software world, people don’t make a distinction between the lunatic fringe and people like Mark Shuttleworth or anyone in between.
One of these days that’s going to change. The loony fringe will become the loony fringe, and the mainstream will go mainstream. It’s happened with every “movement” to come from off the radar, and it will happen to us. In the meantime we need to start controlling the story – reminding people what’s important, and generally drowning out the fringe.
December 20, 2008
community, freesoftware, General, gnome, marketing, work
5 Comments
Reposting from Neary Consulting: This is an article accompanying the presentation I gave at MAPOS 08 in London on December 9th 2008.
Moving the Mobile industry from purchasing to co-development in free software communities
Recently, Matt Aslett wrote an article about the way that attitudes to free software evolve over time within a company, using a graphic he got from the Eclipse Foundation, based on some Nortel funded research. Software sneaks in on the ground floor, going from simple use of components to a real understanding of community-driven development, resulting, long-term, in building free software projects and strategies.
Matt sees an evolution in attitudes as the software and its value is discovered at different levels of the organisation, before finally the business development side of the company picks up the ball and drives free software into the heart of the company’s product strategy.
I have also seen this learning process in action, but I would express it differently. People discover the value of the freedoms granted by free software one by one, more or less independently of their level in an organisation – exploring each freedom before discovering its limitations, and thus discovering the value of the next freedom, and qualifying for the next level.
The core freedoms in the Free Software Definition which are granted to the user of free software are:
- Freedom to use
- Freedom to modify
- Freedom to share, freedom to redistribute
- Freedom to participate
As companies start to integrate free software components into their products, they discover the value of these freedoms one by one.
Use
The first thing that people see about free software is FREE! As in zero cost. The days when companies reject a product out of hand because they don’t have to pay for it are gone – Linux, OpenOffice.org, Apache, Red Hat and a plethora of other “free” products have proven themselves in the marketplace, and companies are now prepared to allow free software components into their solutions, after appropriate consideration of the licences involved.
To quote one attendee at MAPOS 08, “why would I want to write a compression library, when I can download the best one in the world from zlib.org?” In the area of specialised components for secure communications, compression/decompression, a commodity kernel, and a bunch of other situations, it is appropriate to use free software components off-the-shelf. We expect them to work, and we don’t expect to ever need to talk to the maintainer.
Free software components are in use like this in thousands of systems solutions and commercial products, often without their authors even being aware of it. The main advantage of this for a systems or product company is a saving of time and money, through having a fully functional component without having to go through a purchasing process, and a reduced software bill of materials. An additional advantage is the simplification of your licensing due diligence, thanks to the relatively well-understood consequences of the various popular free software licences.
The difficulty arises when the software doesn’t meet your needs. In many cases, libraries are written by an individual to scratch an itch – it works for him, but is not quite up to your requirements. As one friend of mine put it: “Open Source: 80% as good as the last guy needed it to be”.
Perhaps it’s software that works on 32 bit platforms, but has never been tested for 64 bit. Perhaps it has not been ported to ARM or MIPS. Or perhaps the author simply never imagined that anyone would want the feature which you find indispensable.
In this situation, you can always ask the software author to write the feature or fix the bug for you – but since there is no client/supplier relationship between you, it is entirely reasonable for a volunteer to put your request on the long finger, or reject it outright.
At this point, you realise the value of having the source code – you can modify the software to meet your needs, or pay someone else to do it for you.
Modify
Being able to modify software that doesn’t quite meet your needs is amazing. This is the way things used to work by default, but the shrink-wrapped software revolution of the 1980s got everyone used to the idea that software was a valuable asset to be protected from public view at all costs. When I worked for Informix in the late ’90s, we used to refer to the source code of our leading product as “the crown jewels”.
With the widespread acceptance of free software as an alternative, developers are no longer surprised when they may see how a program works, and change its behaviour. This ability brings two important and immediate benefits – you have control of the behaviour of the software, and you can adapt it to suit exactly your needs. The old choice of build vs buy has become: build vs buy vs extend.
This situation is common in software services companies which provide vertically integrated “solutions” to corporate clients. You take components where you can find them to speed up initial development, stick everything together with duct-tape, hack whatever you need in whatever libraries you’re using to make everything pass the client’s integration tests, and then publish a set of .tar.gz files somewhere on the website of the company to fulfil any licensing requirements.
This control and ability to tailor a solution comes at a price, however. Over and above the cost of making the changes, your team is lumbered with a maintenance problem. Let’s say that implementing the features you need on top of a component the first time round takes a month. Fixing bugs in the features when it has been rolled out can take another few weeks. A few months later, the upstream product you’re based on goes and releases a shiny new version, with lots of compelling new features that you really want.
The cost of integrating your features into the newer version, and doing extensive regression testing before rolling out the new version, might take you another 6 weeks. It is not unusual for time spent integrating your work into later versions to quickly outweigh initial development time and investment. Inconveniently, this is typically effort which is not budgeted for beforehand.
After a company has run into this problem a couple of times, over the course of a year or two, someone will usually suggest that you propose that the features you have developed be sent upstream to the projects you work with – if the feature is accepted, you have solved your maintenance problem, it will be in all future releases of the project, and all of that tricky integration work and regression testing work will get done upstream, as part of normal maintenance.
Redistribute
And so you tell your star hacker Jack that he has two weeks to get your 5,000 line patch down to manageable size by getting your work integrated upstream. (when I said this at MAPOS, no-one laughed – so maybe this does not sound as ridiculous as I thought it did).
He diligently goes to work, cleaning up his code, getting rid of all the warnings, spliting up the big diff into small manageable chunks, creating accounts in 10 different bug trackers, signing up to a dozen mailing lists, creating 47 bugs with terse descriptions, attaching proposed bug fixes, and for major features he sends email telling people that the feature is there and asking for review.
By the end of a frantic month, two weeks more than he was given, he reckons that if everything he’s submitted is accepted, your 5,000 patch will be down to a more manageable 2,000 line patch.
What happens next is… underwhelming.
Major features and bug fixes lie unreviewed for weeks or months. Those that are reviewed need changes which take time and effort. Some patches are rejected outright because they’re too big and the feature is difficult to review.
A post mortem analysis of the project of “giving back to the community” might identify some of the following conclusions:
- Not enough time and resources were devoted to advocating your changes upstream
- Personal relationships between Jack and the project maintainers led to a much higher acceptance rate for patches and feature requests
- The projects were initially evaluated on technical grounds, no thought was given to the developer community underpinning it
- In some cases, maintainers priorities were ill-understood
There are two common conclusions that people make from this kind of analysis;
- It’s not worth it. They don’t want our work, and the time we’re spending is costing us more than maintaining out-of-tree patches
- Perhaps if you had engaged with the projects before modifying them heavily, or had been regularly sending contributions, that the maintainers would have been more encouraging, and might have been more prepared to consider your work. If someone from your company was a maintainer or committer already, you would have had a valuable short-cut to getting your agenda implemented in the upstream project.
If you choose door number 1, you will go no further in your quest to really understanding free software processes. This is a reasonable thing to do, but the costs involved are often miscalculated. In addition, the benefits of influencing upstream projects are often vastly underestimated.
If you choose door number 2, you have concluded, in short, that it is madness to include a component in one of your products and exert no influence with upstream projects.
Participate
To have influence, you must understand how the community around a project works. Someone within the team must become an active, trusted member of the community. Once they have gained the trust of the community through their contributions, there may be some procedure to follow for them to become a maintainer of the project, or to gain commit privileges.
These considerations are not technical, for the most part. Friendship and trust are fuzzy human concepts. And this more than anything else brings me to my final point.
Community is hard
For a start, every community is different. They all have different people, different behavioural norms, different dynamics, different forums for communication.
Taking GNOME Mobile as an example, there are 18 projects in the GNOME Mobile platform, with another 10 or so in incubation. Within that, we have a large number of projects housed on gnome.org, and governed by our rules, procedures and conventions. And yet each project has its own set of maintainers – GTK+ is maintained by a committee of around 10 people, EDS is maintained principally by Novell employees, gtkmm has one core maintainer, and so on.
On top of this are a number of freedesktop.org projects, and a couple more which are not under either of these umbrellas. To be an effective influencer of GNOME Mobile, you need to learn the culture of over 20 projects, of wildly varying sizes and baggage.
There are a number of issues to bear in mind when you approach a free software community for the first time. The main one is that while the vast majority of projects think that they are welcoming people with open arms and are very welcoming, if you are a stranger to their land, it is very likely that you will be getting exactly the opposite message.
In some cases, the extent of the welcome is “go and read wiki page telling people how to contribute to the project”. In other cases, no wiki page exists. Occasionally, you will be told that you’re asking your question on the wrong mailing list, or in the wrong way, or that you should read the relevant documentation first. It is not unusual for people to answer questions with a very terse answer – perhaps a link to a mailing list discussion or web-page where the answer can be found.
In general, all of these things are intended to fulfil a simple goal – get you the information you want as quickly as possible, in a way that wastes the time of people already in the project as little as possible. An admirable goal indeed, but as a newcomer, this is not how people are used to being welcomed. Eric Raymond wrote extensively about this in his essay “How to ask questions the smart way”.
Indeed, one of the hardest things to do as an outsider looking in is to evaluate when a community is healthy and viable, and when it has problems which will prevent you from working effectively in partnership. Few resources which talk about healthy free software community projects exist – “Producing Open Source Software”, by Karl Fogel, is something of a bible on the subject, and should be required reading for anyone considering investing in free software. I have also found some presentations, including Simon Phipps’s 2006 OSCon keynote “The Zen of Free” and “How Open Source Projects Survive Poisonous People” by Ben Collins-Sussman and Brian Fitzpatrick, to be excellent resources in helping identify traits of what makes up a healthy community. Two other useful papers which include metrics on measuring the openness of a community, including its governance model, are Pia Waugh’s “The Foundations of Openness” and François Druel’s Ph.D. Thesis (in French) “Évaluation de la valeur à l’ère du Web ” (PDF – rough translation: “Measuring value in the era of the Web”).
Some of the considerations when evaluating a community are whether there is clear leadership, whether that leadership is an individual, a group, or a company, how the leaders are chosen (if they are chosen), what technological and social barriers to participating in the project exist, whether the community processes are documented and transparent, what recourse one has if one feels badly treated, what the behavioural norms of the community are (and whether they are documented) – the list goes on. Pia’s paper in particular gives a great overview in the section “Open Governance”.
Call to arms
And so I close with a call to arms to both free software communities, and companies planning on developing an “open source strategy”.
First, developers, document your communities. Think of yourselves as guides, explaining the cultural quirks of your country to a newly arrived immigrant. Be explicit. In addition to explaining where and how your community works, document how one gains trust and responsibility. Ensure that a newcomer can learn quickly what he needs to do to become a citizen and from there a project maintainer. I am not saying that it should be easy for someone to become a maintainer. What I am suggesting is that it should be easy to see how one becomes a maintainer before doing it
Next, project managers, software developers, company leaders: please, please, please – save yourself time and money and, when you reach the point where you will be building products which depend on good free software components, let the second thing that you do, right after a technical evaluation, be to evaluate the health of the community. A community where you can earn influence and guide the project to better meet your needs is a better long-term investment than betting on a slightly technically superior solution with an unhealthy governance model.
You are building products that you will be selling, supporting, and hopefully profiting from. In this situation, does it really make sense not to have the developer’s ear?
