Posted on

Book Review: The Starfish and the Spider & Open source software organizations and money

The Starfish and the Spider compares two types of organizational structures. Spider organizations have a central command structure, like a CEO. If you detach one of the spider’s legs from the head, the leg can no longer function. It is not autonomous. Starfish organizations have very distributed command structures. Cut off a leg and it will continue to function and will even grow other legs and turn into its own starfish. Each type of organization has its benefits and drawbacks and each are useful at different times. One key to success is understanding what type of organization you are in, its strengths and weaknesses and when you might want to act more like the other type. Hybrids are also possible. For example, GE  under Jack Welsh transitioned from a spider to a spider/starfish. Traditional companies tend to be more like spider organizations and open source software projects tend to be more like starfish.

Some of the points in The Starfish and the Spider made me wonder whether money can change an open source project into a more traditionally organized and closed project. And if it has that potential, what we can do preserve the best of open source while introducing money.

As I discussed in “Would you do it again for free?“, I’m very curious about how open source organizations work and in particular how factors like motivations, companies and pay change them. I’ve theorized that pay can change an open source developer’s motivations. It’s not usually bad for the project (especially if the payment is in the form of salaries) unless the money goes away. If the money goes away, if for example the developer gets laid off, then I think the developer will quit working on the project but will switch projects, not quit working on open source software projects all together. (Assuming they were working on open source software before they got paid to do it.)

But what happens when money gets introduced suddenly into an open source project? I think it depends on how the money is used and how much its distribution changes how the project is run. In most cases, access to money has greatly helped open source software projects in a number of ways.

  1. Developers. There are a lot more developers working full time on projects like Linux and Firefox than there would be if no one was paid to work on them. And those developers contribute more than just work. They bring ideals and values to the project.
  2. Team building & communication. More resources means being able to bring more people together – and not to just hold the conference but to actually pay for people’s travel expenses if needed. GNOME, Apache and Mozilla all help pay for contributors travel to key events when needed.
  3. Infrastructure. Money can also provide for project infrastructure, hardware and hosting costs.
  4. Skills. Money can also be used to bring in resources that open source software projects have traditionally had a hard time recruiting or finding in their volunteer staff such as marketing and business development.

Given all the benefits that additional resources can bring a project, I think having access to money is definitely a good thing for open source software projects. (And I’ve spent a lot of time personally helping projects effectively raise and use money through efforts like fundraising for GNOME and serving on the Board of Directors for the Software Freedom Conservancy.)

I do think there are a few things to keep in mind though.

  1. Money often concentrates power. This is not so much an issue when the money is used for salaries, but more an issue of when resources for things are not accessible to all project members. Or the process for getting access is not communicated well. The Starfish and the Spider shares the example of how the Apache Indians were ultimately defeated. The Apaches were definitely a starfish organization. Tribes followed their leaders because they believed in them. If a leader was killed, people would continue to fight and a new leader would emerge. How were they defeated? By cows. The Americans gave the Apache leaders cows. Once they had cows, they controlled a valuable resource and became an authoritative leader and the power structure became hierarchical instead of flat. Once the organization was hierarchical, it was easier to control. So it’s important to make sure that control of resources reflects or supports the project structure.
  2. It’s hard to spend money. Many open source software projects, especially those with relatively small amounts of money, struggle with how to spend the money effectively and fairly. If you have $500 and a project with 10 people, how should you use it? You could reward everyone with a dinner at a conference, but most of them would probably rather you spent the money on the project. You could pay to fly someone to the next hackfest that would not ordinarily be able to afford to attend. With a little bit of money (I heard under $10,000), it is often hard to spend the money. It’s more work to figure out how to spend it and use it, than it’s typically worth. Especially if the project doesn’t have an organizational entity associated with it.
  3. Most financial transactions require an authorized person. In most countries, signing a deal with another organization requires someone to sign the deal. So to enter into any kind of business relationship whether as a client or a partner or a provider, an organization must have someone with authority to sign for the organization. And for tax and liability reasons, you need an organization to collect money and sign agreements. It’s possible to give that authority to someone in a way that’s consistent with the values of a starfish organization, but it requires some thought.

Money can do a lot of good for open source software projects but some thought needs to be given to using it in a way that will do long term good.

Posted on

Universal Subtitles

I found the coolest tool, Universal Subtitles. With Universal Subtitles you can easily transcribe a talk, add subtitles or captions or translate any video on the web.

I’ve been trying to transcribe my Would you do it again for free? talk forever and I always give up – I can’t type fast enough to keep up and manually pausing required more hands than I have. Universal Subtitles let me type and automatically paused and let me catch up whenever the video got ahead of me. Then I could go back and edit, adjust the timing, etc. Now I could also go back and translate the subtitles into other languages.

Universal Subtitles is an awesome tool to help people share videos and presentations in other languages. Not only does it give you the tools you need to do the job, but it makes it very easy to cooperate. So for example, I could transcribe a GNOME video and then someone from the GNOME Hispano community could translate the subtitles into Spanish and then someone else from the GNOME localization team could translate them into their language. Others can go back and make corrections and adjust timing.

(Note that while the Universal Subtitles tool is awesome, transcription is still hard! I was transcribing myself and I still had trouble at times!)

Universal Subtitles is open source software and funded in part by Mozilla through Mozilla Drumbeat.

Disclaimer: I work for Mozilla.

Posted on

Forking an open source project: regaining internal motivation

Can forking a free software project enable you to regain your internal motivation to work on a project? My current theory is that if you work on free software, then you get paid to work on it and then you get laid off, that you would work on a different project. Because the first one is no longer good enough to get paid, then it must not be good enough to work on for free.

If my theory is correct, then I think there’s a great trend going on. Ex-employees are getting around this mental block by blaming the failure (the fact that they can’t get paid to work on it anymore) on the company’s strategy and forking the project to create a new one that they can then justify working on.

One of the strengths of open source software licenses has been that you can fork the project. If at some point in the future, you don’t like what the project is doing, you can take your copy of the code and go do your own thing. Many have argued that it’s that right to leave that makes people work hard to get along. Nobody wants to fork a project is the theory.

Recently most of the forks we’ve seen have come from ex-employees who are unhappy with the direction their previous employer is taking the project.

For example, take Mandriva/Mageia. Part of the Mandriva community, including ex-employees of the company, is forking Mandriva and creating Mageia, a new Linux distribution.

Their website doesn’t say exactly why they are forking but says they no longer trust the company’s motivations. The move seems to be prompted by layoffs:

Most employees working on the distribution were laid off when Edge-IT was liquidated. We do not trust the plans of Mandriva SA anymore and we don’t think the company (or any company) is a safe host for such a project.

Certainly I can see how people who have been laid off would no longer trust the company.

It does look like Mandriva is restructuring to give  more power to their community. However, I doubt they will reverse their decision to move the desktop development to Brazil. In addition to having lots of great free software developers in Brazil, I bet development costs are much cheaper in Brazil.

In the mean time, the ex-Mandriva employees have created a project worth working on for free, Mageia. Something they care about and can invest in, an independent, community run distribution with a community and an associated nonprofit organization.

I wish Mageia the best of luck with their project and I wish Mandriva the best of luck with their company. I think they will both solve different problems in different ways. And I’m really glad that the Mageia will continue working on what they love even if they are not currently getting paid to do that. Their project is worth it.

Posted on

Why do you have to pay employees to do the right thing?

Photo by eyetoeye

Energizer Battery Company is rewarding employees for flying coach. If employees fly coach, the company splits the difference with them – up to $2,000 for trips to Europe.

This just seems really strange. Let’s put aside the fact that employees are now getting a $1,000 bonus for flying to Europe, so they may be inclined to fly more. (That’s about $50/hour to sit in an economy seat! I’d consider a job doing that.)

At first glance this seems like an awesome deal. The company saves money, employees make money, everyone’s happy.  I’d be a lot richer if I got this deal. But I fly coach without an incentive. Or rather the incentive is that I think the GNOME Foundation can do better things with that money.

That’s the key. Obviously, that business class seat isn’t worth the the $2,000 more the company was paying for it. It’s not even worth half that much to the employee! The company is counting on the employee being willing to sit in economy for $1,000.

So why were employees flying business? Because they didn’t care that the company would be $2,000 poorer. They don’t think the company will do anything more important to do with that money than fly them in business. They either don’t have enough say in how the company makes financial decisions or enough visibility into the process to feel like that money would be wisely used. Or they don’t care about what the company is trying to do.

That is what this company is missing. Employees need to know the money they are saving is going to go to good use. It’s hard to stay in a budget hotel if you know your CEO is staying in a 5 star hotel. It’s easy to stay in a budget hotel if you know your company is going to ship 10 more computers to underprivileged kids with the $2,000 you saved.

The bigger problem here is that employees are either not bought into the company’s mission or they do not trust the company’s financial decision process.

Posted on

Unexpected rewards are better than expected rewards

Since I’ve started talking about Would you do it again for free?, I’ve been very interested in any studies that show how extrinsic rewards change intrinsic rewards. The theory is that external rewards can replace your internal values to the point that you’ll no longer do what you valued without external payment or reward of some type.

This study showed that unexpected rewards are better than expected rewards. They took kids who liked to draw and put them in three groups. One group was:

  1. told they’d get a reward for drawing
  2. not told they’d get a reward but got a surprise reward when they were done
  3. not given anything

Then they watched the Rewardkids over the next few days and discovered that those who had received the expected reward drew the least while those who had received the unexpected reward drew the most. (Even though there were now no rewards promised nor given.)

This would mean that in the open source world, unexpected rewards after the work has been done would be the most motivational. Like the GNOME thank you pants, an annual award for outstanding service to the GNOME community. As opposed to bounties or employment. (Not that people shouldn’t be employed or that bounties should be used, but just that according to this study, those types of payment are unlikely to increase motivation.)

Thanks to Dawn Foster for the link.

Posted on

Supporting free software with grant money

I recently started investigating how GNOME could fund projects with grant money. Will Ross sent me an email with a lot of good information and I’d like to share his experience with others in the open source software community.

DSCF0535aWill Ross is a project manager with Mendocino Informatics, a small healthcare technology consulting firm in Mendocino County, California. Prior to Mendocino Informatics, Will was CTO for a consortium of nonprofit community clinics, and before that worked on the network infrastructure teams for two Bay Area dot-coms that *didn’t* fail (Organic Online & LoudCloud). Will spent the 90s as CIO for a mail order company and writing SQL queries for a multinational manufacturing company.

Hi, Will. You have successfully developed a business that provides open source software to healthcare organizations funded by grants. Can you tell us a bit about that?

I work in community-based nonprofit health care. Using grant funds to develop open source software is my standard procedure. Specifically, I write grant proposals to foundations who fund health care software deployment projects. When I get the grant, instead of buying some COTS package I use the funds to add features to an open source project, or to write a technical implementation guide and release it under an open source license (see the ELINCS guide on my home page). In most cases the foundations are uninformed about open source intellectual property issues. It is typically not a requirement of the grant that I invest the project funds in open source, it’s just something that I do because of my personal convictions about the need to restore balance to the
intellectual property commons.

Have you been successful?

I have been self-employed at this since 2004. Since then I’ve used grant funds to purchase about $500 k in software engineering development for three open source health care projects — OpenHRE, ClearHealth and Mirth. Right now I’m working exclusively on the Mirth project, and have recently lined up an additional $100k in funding to develop further features on the product roadmap.

How do you go about writing grant proposals?

Basically, as an IT project manager I work entirely at the application layer within the health care sector. I start with the general list of tasks that need to be done in the field. I investigate software functionality from a user-centered workflow perspective. That is, I don’t impose software on users, I look at their current workflow with an eye towards optimizing the business rules and disrupting COTS solutions with FOSS solutions. This process identifies gaps where FOSS tools are not yet enterprise class, and where my grantwriting can raise the quality of FOSS tools to the expectations of enterprise CIOs. Then, knowing what I need to build, I pay attention to any grant funding that becomes available. Right now I’m working on proposals that will apply for funding from the HITECH act recently passed by Congress.   Grant opportunities ebb and flow. When one opens up that is a good match for the opportunities I have identified, then it’s typically a three or four week deadline to gather all the details, pull stakeholders together and write a credible proposal.

How often are you successful getting a grant?

Writing a proposal is a huge time sink with no pay; that is, it’s entirely a business development write off. I try to focus only on grant opportunities where I have a good chance of success. When I find an opportunity, I write a proposal. Overall, my track record as a grant writer is probably about 30%. That is, I write about 10 proposals a year and get 3 or 4.

What advice do you offer to open source organizations looking for funding?

I want you to know that you have friends in the field — software users who are annoyed by and dislike their current cumbersome COTS tools. Study the user experience at the level of the business rules their software makes them follow, and look for opportunities to optimize their work flow by migrating them to new, more agile FOSS tools. In shops that already understand FOSS applications, you may be able to write grants to “purchase” open source software development, as
I do.

What do you use the grant money for? Do you pay yourself?

The exact sequence of steps is that I write proposals for free, sometimes investing more than 100 hours into a proposal. If a proposal is funded, then as the project architect who developed the specific technology roadmap, I get the project management contract. In terms of the whole lifecycle of the process, I get paid for about 60% of my time, and the rest is invested in studying the sector, attending conferences, serving on public committees and becoming conversant with
the user perspective in the market vertical.

I’m not a coder. I’m a project manager who writes grant proposals so I can have interesting work and live in a rural area. When I get a grant, I pay professional coders to write the apps. Currently I am working on a huge suite of Java apps (for Mirth, which is published under the MPL) that will disrupt the business lines of several major COTS network app vendors in health care. The short version I tell people is that I write grant proposals to develop free software that can be given away to nonprofit health care facilities. The reality is a little more complicated, but its generally too much information so I try to keep the story short.

Do the grant organizations give you preference because you are developing free software?

The funders generally do not pay attention to whether their grantees are buying COTS or building FOSS.  When I propose a project to a funder, about half the time it is not relevant to mention that the funds will be spent on a FOSS solution;  it would be too much information to the funder. Also, I got burned once when I didn’t read the fine print in a grant contract and later I discovered that I was prohibited from releasing that work as FOSS, but otherwise it has not been an issue. I guess the more important point is that at a basic level the foundations are generally so tactically focused on their mission that they don’t “get” the underlying strategic social value of a rich intellectual property commons, so in most cases they treat a FOSS pitch as incoherent babble that is off topic from their particular social agenda. So, a lot of the time I leave out the FOSS part and present the funder with a project that does the specific things they are mission driven to accomplish.

What advice do you offer to developers looking to fund work on open source software projects?

Find operating nonprofits in the service sector with FOSS savvy CIOs who need enterprise class tools but are stuck with legacy COTS apps, and then look to the funders who support those nonprofits. That’s my story. I get it because I was a CIO in the 1990s, and FOSS tools that were enterprise class were easy to integrate into my shop.

Thanks, Will, for sharing your expertise with us!

I’d like to encourage the GNOME community to submit ideas for GNOME projects, http://live.gnome.org/Grants.

Posted on

Companies: fostering or controlling communities? An interview with Kim Weins

IMG_3907
Kim Weins is the Senior VP of Marketing at OpenLogic. Kim spent three years as a principal in CMO Strategy Group and helped companies such as Atomz (acquired by WebSideStory), TuVox and
RedSeal to significantly accelerate their marketing efforts. Prior to CMO Strategy Group, she was at PeopleSoft where she was responsible for driving PeopleSoft’s CRM business strategy.

I had lunch with Kim Weins from OpenLogic. We had an interesting discussion about open source companies and how they can either dominate or foster communities. In addition, we also talked about what it’s like for an open source software developer to work for an open source company. She works with many open source developers on a contract basis as well as many open source companies on a partner basis. Her insights were interesting.

Kim, “open source companies” come in many types and flavors – how do you characterize them?

We see two main variations of open source companies – differentiated by the level of ownership and control over their IP. This level of control is important, because it tends to drive their business models.

The first type what I’ll call “IP owners”. These are companies that own and control all of the IP that goes into the open source product. This would include companies like MySQL, Alfresco, SugarCRM, etc. These companies typically have some variation of a dual licensing business model that requires that they control all of the IP in order to license an “enterprise version” of the product in the way they want – often not under an open source license. For these types of companies, typically only employees can commit changes to the project since the company wants to maintain control of the IP. In
some cases, the companies may allow contributions by outside committers, as long as the developer gives IP rights to the company.

The second type is what I’ll call “non IP owners”. This type of open source company typically builds up around an existing open source project that has many committers. The IP is owned by the open source developers or by a third party such as the Apache Foundation. Examples of this type of company would include Enterprise DB, Acquia, or Red Hat (around Linux). Since the company often does not own or control the core IP for the project, the business model changes. These companies typically either sell support and services around the project or create add on functionality that they can then license. Often the companies will hire some or all of the committers on the projects, but typically the projects are open to contributors and committers outside the company to participate. However, there are some cases where these companies try to gain control over the IP by hiring all of the committers so that they can determine the direction the project takes.

While it’s great that developers can get hired to work on their project, sometimes it seems like the open source company hires everyone in order to control the product. Can an open source company hire too much of the community?

When the developers working on a project are limited to people employed by one company, it eliminates a huge part of the value of open source development. The ability to build new capabilities is then limited to what can be funded by one
company – just like for proprietary software. Although some open source companies would argue that they help to support and fund the project in this way, the reality is that they also gain control. If their sole interest was in supporting and funding the project, they would open up to committers outside the company in order to improve the project more quickly.

Many open source software developers do quite a bit of contracting or consulting work, like for OpenLogic’s Expert Community. Does working for an open source company make that easier or harder
for them?

We work with the OpenLogic Expert Community on a contract basis. They are not employees of OpenLogic, but we pay them for the work they do to help support our customers. This allows them to continue to work on other projects (whether for pay or volunteer) as they see fit. However, in recruiting these open source developers, we find many cases where their employer, whether a proprietary or open source company, tries to limit their ability to work on open source (whether for pay or volunteer). Companies do this through employment agreements that specifically limit a developers ability to work on outside projects, either by requiring IP assignment of anything they develop to their employers or by explicitly forbidding certain kinds of outside work. These restrictions may make it harder for developers to participate in the open source community as they see fit.

Do companies often foster open source developers? i.e. if you want to get going working in open source software, is getting a job with an open source company a good way to get started?

In some cases, companies do foster open source developers. However, the companies that do so by trying to tie developers hands are doing a disservice to the developers, the open source community, and eventually themselves. When going to work for an open source or proprietary company, open source developers need to be careful to negotiate the freedoms that are important to them – such as having the right to work on other open source products and the ability to retain IP rights in the work they do.

As well as the ability to work on non-related open source software projects in their free time!

Can you give an example of a company that you think is doing a really good job of working with the community or maintaining an independent community?

I would cite two examples that represent how companies can be successful while maintaining an open community. The first would be RedHat around Linux development. Linux is not controlled by any one company – rather it is contributed to by multiple vendors as well as independent developers. Obviously full credit for this can’t go to RedHat, since they need to work within the constraints of how the Linux project is structured, but they have done a good job of demonstrating that you can make money and be  successful without controlling the IP.  It remains to be seen if that same model will be true for JBoss.

The second example would be Mozilla around Firefox. Mozilla has developed a business model that seems to work without limiting community involvement.

Many companies have open source products but not an external open source community, what benefits of open source software do you think they are missing out on?

There are several benefits of open source, but some of the most important benefits come from having a broad, diverse and open community. By doing so, there are economies of scale by sharing the development and maintenance efforts. There is also a breadth of requirements and a breadth of technical solutions that may be limited when all developers are internal to the company. Companies that don’t stay open to a community that extends beyond their employees will really be returning to some of the limitations of proprietary software.

Thanks, Kim.

Anybody else, thoughts to share on open source companies, communities and employment?

Disclaimers: I used to work at OpenLogic and I still occasionally do some writing and consulting for them. OpenLogic pays open source software community members to support open source software projects on an issue by issue basis for Global 2000 companies. I approached Kim about doing this interview.

Posted on

Does money kill good motivations?

I get asked a lot about my “Would you do it again for free?” talk. (“Would you do it again for free” was about the question, if you take developers that are working on open source software for free and you pay them, if you stop paying
them, will they still work on open source software?  This was the topic of my keynote at GUADEC, LinuxConf Australia, and SCALE – the talk evolved over time. The next step is to communicate how companies can work effectively with communities.)

I’m working on a transcript for the talk as the slides don’t standalone. However, it’s taking a long time (as I don’t spend much time on it) and I got asked again for reference material. I’m still working on the transcript but in the meantime I thought I’d share the studies I talk about it the beginning of my talk as that’s often what people ask about.

I found the following five studies that explore how external rewards affect internal or intrinsic rewards:

  1. NYC “pay for grades.” New York City is offering financial incentives to students to encourage them to do well in school. Kids are being offered up to $500 a year to take the standardized tests, get good grades and attend school regularly.  Barry Schwartz, author of The Paradox of Choice is very critical of the plan.  He says that by paying them we may actually make them less likely to want to go to school (unless they are paid.) Instead he says we need
    to figure out why kids don’t want to do well in school.  We need to work at making them internally motivated to do well in school.
  2. Kids & Crayons. In the same New York Times editorial, Barry Schwartz pointed to another study that shows how external rewards can kill intrinsic motivations. This study was done with preschool kids – they were given some special markers.  Some of the kids were given awards for playing with the markers and some were not. Those that got rewards were less likely to play with the markers again and less likely to draw pictures. They associated drawing pictures with earning rewards not with having fun and so were less likely to draw pictures just for fun!
  3. Swiss nuclear waste. In a slightly different twist, a study was done to see if external rewards were more or less motivating than internal rewards from the onset.(Actually, I don’t think that’s what they were studying but that’s the question they ended up answering.)  A few years ago Switzerland was trying to figure out where to put its nuclear waste – no town wanted it.  Researchers went door to door and asked people if they would take the waste in their town.  When they were reminded that it was their duty as a Swiss citizen, 50% of them said ok.  When they were told they’d be paid a substantial sum (about six weeks pay every year,) only 25% of them said ok!  It wasn’t worth the money. [Found in Motivating Crowd Theory from Luis Villa’s post. I heard it was also covered in Sway: The Irresistible Pull of Irrational Behavior.]
  4. Israeli Daycare. An Israeli daycare also conducted an unintended study on motivations. They were tired of parents arriving late to pick up their kids, so instead of giving the parents a hard time and explaining that their workers wanted to go home on time they decided to start fining parents. Parents saw the fine as sanctioned baby sitting and started showing up late even more often. They no longer had to feel bad about showing up late because they were paying for the service! The scary thing (for the daycare) was that when they removed the fines (because parents were showing up even later,) parents didn’t go back to their original behavior!  (I think the daycare must not have charged enough. My daycare charges a $1/minute and I have to say that’s motivating!  Although I am more motivated by the embarrassment of being the last parent and of making my kid feel bad.) [Dave Neary pointed me to Luis Villa‘s post on this one. I also read about it in Freakonomics.]
  5. Household chores. Motivation crowding theory cites a study that found that kids that were paid to mow the lawn would only mow the lawn if they were paid to mow it.

So the question is, can those studies be applied to open source software? And for that you’ll have to wait for the transcript or watch one of the videos of my talk. (The short answer is, it applies, but money is not as demotivating as you’d first think for a number of other reasons.)

Posted on

Social Norms vs Market Norms

Social norms govern whether you are willing to help a friend move or cook dinner for your family. Market norms govern what you are willing to do for how much money. In an experiment to show how social norms vary from market norms, Dan Ariely created a computer task where volunteers had to drag circles into boxes. He then divided his volunteers into 3 groups.

  • Group 1 got $5.00.
  • Group 2 got either 50 cents or 10 cents.
  • Group 3 was asked to do him a favor.

Not surprisingly, group 1 – the highest paid group – outperformed group 2, but group 3 – the volunteer group – outperformed them all.

He went on to talk about how that affects employer-employee relationships. While market norms are at work, employees are asking for a lot of social norm like stuff, working 24×7, giving up holidays, etc. When they don’t repay in “social norm” stuff like time off when the kids are sick, employees immediately feel cheated.

What was interesting to me from a “Would you do it again for free?” perspective was:

“when a social norm collides with a market norm, the social norm goes away for a long time. In other words, social relationships are not easy to reestablish.”

To me, that would mean that once you are paid to work on open source software, it would be hard to go back to doing it for free.

Although based on other research I’ve read, I think open source software developers – ones who did for free, were paid, and then were no longer paid – would move to a different open source software project rather than quit altogether.

Another tidbit, relevant to Friends of GNOME: gifts don’t change how hard volunteers work unless it’s pointed out what the gifts cost.

Posted on

Are volunteers more dedicated than paid staff?

As many of you know I’m fascinated not only with how the open source software model works but how companies are unintentionally influencing the model by injecting money. I’ve shared my research and thoughts in my “Would you do it again for free?” talk.

So when I saw Volunteer staff are surprisingly committed, I was not surprised to see that volunteers were more committed on average than paid staff. I was surprised to see that the study authors decided that it:

could have to do with the fact the volunteers
tended to be older. “Older people are motivated to volunteer because of
their wish to fulfil an obligation or commitment to society,”

They forgot a few things like:

  • Were the paid staff volunteers before they got paid? Or were they recruited to the organization with a paycheck?
  • Do the volunteers get more (or less) say in what they work on?
  • Are the work conditions and hours the same for volunteers and paid staff?
  • Do they do the same types of tasks?

…and so on. I would bet that not all of the paid staff were volunteers first, and that while volunteers are drawn to an organization because they believe in the cause, paid staff are drawn because of the cause and the paycheck. Some might do it more for the cause and others more for the paycheck, but it’s not so clearly for the cause like the volunteers.

(Disclaimer: I was not intrigued enough to pay $28 to read the original article, so I just read summaries and abstracts.)