Category: open source

Posted on

Humanitarian projects bring more students to open source software

I learned about an interesting project at the Grace Hopper conference: the Humanitarian FOSS Project.

The Humanitarian FOSS project is attracting new students to software development by appealing to them with open source humanitarian projects. They’ve had a lot of success over the past two years. They bring all the students together on a university campus, house them, pay them and give them open source software projects to work on. The students have access to each other, professors and remote mentors from the project. Past projects have included working on disaster recovery software, volunteer scheduling software and medical imaging software. Their project is 100% funded by an NFS grant right now although they’d like to have companies fund additional interns in the future.  A huge additional benefit from my perspective is that the humanitarian aspect brings in people that might not traditionally
have been drawn to open source. (They were at the Grace Hopper conference because last summer’s group included quite a few women.)

I had a follow-up phone call with Trishan de Lanerolle, the project director, as well as Professor Ralph Morelli from Trinity College, and they proposed having two students work on GNOME projects next summer! They would find, house and fund the students. GNOME would provide (humanitarian) projects and mentors.

It’s a great offer and I’m thinking GNOME has a lot of great projects that would fit the humanitarian aspect, especially accessibility related projects.

Posted on

Open source marketing is like manning an info desk

At the Openismus party in Berlin a few weeks ago, I had some interesting conversations about what marketing for an open source project like GNOME should be. What’s our core message and who are we targeting? (I think the best ideas come from discussions with others who care about the subject. Luckily with open source, everyone is passionate about the projects they work on so I get to have lots of really interesting discussions and hear lots of good ideas. I realized later I always talk shop at open source events. So if you don’t like talking shop, you should probably avoid me at the next open source related party, although you can sidetrack me by talking about kids. 🙂

There was one comment that we all thought was funny and right on. Jos van den Oever observed that marketing for an open source project is like working at an info desk. In a sense that’s true for all companies. Marketing departments give the rest of the world information about the company. But it’s even more true for open source because the marketing project doesn’t set the direction or strategy or even know all the answers. You direct people to the people that have the answers. Or at least that’s what I feel like I’m doing. Getting questions, finding answers, relaying back … like an info desk.

An infodesk model also implies that you are applying less of a slant to your messaging …

Posted on

What do you have: time, resources or features?

As open source software becomes more popular and is included in more commercial products, the open source software projects face more pressure to produce a “roadmap”. Projects like GNOME have successfully moved to a six month release model which has greatly aided the companies that depend on GNOME technologies. They know when the next release that includes their patch will come out. They can now plan for when patches need to be submitted to make a release, when that release will come out and roughly what it will come out.

With plans for GTK+ 3.0 and GNOME 3.0 being discussed, the pressure to generate a “roadmap” has once again appeared. When will 3.0 versions be released and what will be in them?

The rest of this post is generalizing about open source software projects in general, not GNOME or GTK+ in particular. It’s just that working with them has made me think of these things.

Triangle
One of the factors that is becoming clear to me is that open source software has a fundamentally different “project triangle” than proprietary software. Every project has three constraining resources: time, resources, and scope. (Resources is often called “money” because in the proprietary world it’s assumed you can buy more developer resources.) Some of these constraints are always more flexible than others – the question is which one is most flexible and which one is least flexible for your project. Typically in a proprietary product, it’s scope that’s most flexible. The project has a fixed amount of money and people and marketing’s committed to a release date, so it’s the list of features that’s most flexible. Occasionally the most flexible item will be resources and a company can throw more money at the problem.

In contrast, in the open source world, the most flexible resource is not scope but time. While resources are not fixed, you can’t easily find more volunteer developers to throw at the problem. So for planning purposes, resources are not flexible. While scope is flexible, time is even more flexible.

Typically open source software projects define a release by saying which features they would like to have in a release (which can change if external circumstances change), put all of the volunteer resources they have at the problem and then remain most flexible with regards to time. They release when they’re ready.

Time is sometimes important in open source but not because a marketing team committed to a date but because you want to keep your project active in order to keep people interested in working on it. New features and new releases are exciting.

While each open source software project is different, I believe that community driven open source software projects are probably closer in priorities to each other than they would be to traditional proprietary softwaree.

For proprietary companies used to a fixed schedule and flexible scope, having a flexible schedule is frustrating. It’s not wrong, it’s just very different than the world they work in, and so makes planning very hard for them.

Companies look to open source software projects for a roadmap that’s fixed in time and flexible in scope. While the open source software projects are saying there’s no way they want to commit to a time because they can’t commit to more resources and they know they have to have the following features to say it’s a “major release.” The projects commit to scope (a set of features) and resources (the project members they have and anybody who wants to join us), and releases when they can.

This isn’t to say open source software projects don’t care about time, it’s just the most flexible of their three constraints by the nature of how they work.

Posted on

Ubiquity: turning us all into power users

Ubiquity was officially announced this week. I installed it and I find myself using it all the time for really simple, but very useful, stuff. I use a calculator a lot. Now, when I’m in the middle of typing an email or reading a web page, I just hit two keys and type "calc 3256/3+2456" and there’s my answer. If I see a word I don’t know, I just hit two keys and type "define hello", read the answer and hit escape and go back to what I was doing. If I want to email something interesting that I’m looking at, two keys and "email this to mike" and it emails whatever’s on my web page to Mike. (Actually it gives me a choice as to what "this" is and then it brings up Gmail with an email all addressed to Mike and filled out with the information from the web page I was looking at.)

So easy, so fast.

Have you ever watched one of those power command line users? Or power emacs users? Or even people who use the keyboard exclusively? Their fingers just fly and magic comes out of their computer. I feel like Ubiquity brings that power to the average web user. With just a couple of keystrokes and intuitive commands, they can make the computer magically generate the answer they are looking for.

Ubiquity works in the web browser and can do most things I can do inside my web browser. Now wouldn’t it be cool if Ubiquity also knew about my computer and all the applications and data I have on my computer? So now I could also say "email myspreadsheet to mike" and it would find "myspreadsheet" and email it to Mike?

Luis pointed out that since Mozilla’s projects are all open, and the GNOME Foundation and the Mozilla Foundation work together, we should be able to do that with GNOME. And Abhijit Nadgouda’s post reminded me that we might not be the only ones who’d like Ubiquity to know about our desktop. Plus, GNOME already knows how to do task oriented commands – GNOME Do has provided Ubiquity like functions for a while now. (I’m a big GNOME Do fan as well.) Can we integrate those desktop tasks into Ubiquity?

It seems to me that since Ubiquity, Firefox and GNOME are all open source we should be able to make that happen. It’s a unique opportunity to integrate the web and the desktop. I shouldn’t have to remember what functionality is part of the desktop and what is part of my browser. If I say "add this to myspreadsheet", the data I selected on the webpage should just be added to "myspreadsheet" on my computer.

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

Fundraising for a technical nonprofit

The GNOME Foundation is a nonprofit organization, a 501(c)(3), and is funded by donations from individuals and companies. So as executive director of the GNOME Foundation I figured I should learn a bit more about fund raising.

While there are a lot of books about fund raising, there’s very little information out there about fund raising for technical nonprofits. And technical nonprofits really don’t fit the traditional nonprofit model. (Anybody up for a telephone drive where you call all your friends and relatives and explain what great things we’re doing and ask for donations? Not.)

So what’s the current status? GNOME is doing quite well. We get most of our funding from our corporate sponsors who give annual fees (which I think should more accurately be called annual donations.) We also get quite a bit of money from companies (our regular corporate sponsors as well as a number of others) to fund specific events. For example, GUADEC, our big annual conference, gets funding from our regular corporate sponsors as well as a number of others. Our third biggest source of funding (which is relatively small at the moment) is Friends of GNOME, where individuals can make contributions. (More on Friends of GNOME later, as we roll out some new features and marketing.)

What can we do better? I’m open to everyone’s thoughts on this but here’s a few:

  1. When we ask corporate sponsors for donations, I think we need to focus on what their money will accomplish, not what they’ll get directly from the GNOME Foundation. So we shouldn’t say (as I was originally thinking), if you give us $10,000, you’ll get a seat on the advisory board. Instead we should say if you give us $10,000, with all the corporate sponsor money we’ll be able to send 20 developers to GUADEC, fund a usability study and have three hackfests. (And explain why that’s good for the company or why it furthers the company’s mission.) L. Peter Edles put it this way: fundraising is not begging. People want to be part of a winning team and most philanthropic efforts are to improve quality of life. (Note that the book had some good points but was rather antiquated.)
  2. Speaking of quality of life, we need to be able to explain quickly and clearly why GNOME improves a company’s business, an individual’s life, the quality of life for kids in developing countries, etc. I think we know these things and we have a lot of good stories that we can tell. Pointing out how One Laptop Per Child uses GNOME technologies is a message that would reach a lot of people that probably don’t know what GNOME is.
  3. Friends of GNOME. Friends of GNOME is our program for individuals and organizations to make donations. We do no advertising and yet many individuals and a few companies find our web page and make very generous donations. We are working on revamping this program to make it easier for people to make recurring donations and to spread the word. (This was started before I joined.) The FSF has a very successful associate membership program that brings in the majority of their funding.

So I think we need to continue to work with corporate sponsors as well as our individual fans to spread the word of GNOME!

Thoughts?

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.)

Posted on

Where will open source lead?

In his LinuxWorld keynote, Bob Sutor said that open source hasn’t really reached the enterprise application space yet.

I used to say that the top of the stack was proprietary and that open source enters into a space as it becomes commoditized. That was 2001.

Now it’s 2008 and it’s time for open source software to lead.

The community is big enough, vibrant enough, active enough, smart enough to really lead the way in innovating new products, not just creating open source solutions that are equivalent to proprietary ones. I’d argue that this is already being done in spaces like subnotebooks – the Linux ones boot much faster than the Windows ones.

So the question is, not when will open source be in the enterprise application space, but what open source applications will appear that the enterprise doesn’t have a solution for yet?

Posted on

Afraid you’ll get sued for using open source software? Think again.

I gave a talk at LinuxWorld called "Avoiding Open Source Lawsuits: Five Steps to Effective Open Source Governance in the Enterprise." I suppose it wasn’t the wisest title since my point was to dispell FUD (fear, uncertainty and doubt) not create FUD. (I borrowed the title (and a few slides) from an OpenLogic webinar, although my talk was substantially different.)

The point of my talk was that although I think there’s very little chance you’ll get sued for using open source software, if you (or your manager) are worried about it, there’s a few things you can do to dispell those fears. (My goal is to convince more people to use open source software by dispelling myths and giving people tools to convince the opposition.) By having clear policies and processes for dealing with open source software, a company can ensure that not only will they not be doing anything they could be sued for, but if they are sued (or just approached by someone like the SFLC), they can show them that they were doing their best to comply with open source licenses. If you show you are doing the right thing, open source developers and those that represent them are more likely to help you straighten things out than they are to sue you. Open source software developers in general want their software to be used!

So what should you do?

  1. Find out what open source software you are using. For this I recommend OSSDiscovery. (And once you’re done, go ahead and submit it to the Open Source Census to help spread the word about how much open source software is being used.) But whether you use the tools are not, you should keep track of what you are using.
  2. Establish a clear open source policy. This should include not only guidelines for how your company should use open source software but also training so that developers can evaluate licenses and know when to get help. (For help with this see FOSSBazaar.org.)
  3. Set up a review board. There are always exceptions, new licenses, different ways of using open source software and your employees should have access to experts to help them make an educated decision as a company.
  4. Make sure you are complying with the licenses you are using. To me, the hardest part of complying with open source software licenses is knowing what licenses you are using. Sometimes projects contain lots of different licenses or the project you want to use depends on a number of other projects, all with their own license. Tools like Fossology and OpenLogic’s OLEX can help determine which licenses you are using.
  5. Track and audit. Show that you are tracking what open source software you are using and periodically auditing it and I am sure that if you are apporached by the FSF or SFLC, that they will be more than happy to work with you.

The SFLC is not suing to make money for the BusyBox developers – they are suing to make sure that people are using GPL licensed software appropriately. I did mention a few lawsuits in my talk but it wasn’t to point out how much money people were making (I’m not sure anyone has made any money off suing for misbehavior around open source software) but rather to give specific examples of what could happen. All too often I think people don’t use open source software because they are afraid of "being sued" and they aren’t even really sure what they could be sued for.

To make a long story short, I think there’s little chance that a company that is trying to do the right thing will get sued for using open source software. Especially if they have clear policies and processes that show they are actively tracking, reviewing and managing the open source software they use just like they would track their use of proprietary software.

Posted on

Open source users aren’t your average beta testers

Scoble just lost all his calendar events to a Mobile Me bug. He points out that:

Apple’s secrecy keeps them from properly testing out their apps with
tons of users, the way other companies do who aren’t so worried about
secrecy.

When people talk about open source software, they talk about the advantage of lots of testers. For example, Marten Mickos always talks about how he has two types of users with MySQL, those with lots of time and little money and those with lots of money and little time.

What I think doesn’t get enough attention is the fact that these "free users" aren’t your average user. They are usually very technical, very passionate, very active users. People that will help make sure you have the information to fix the problems they find. And if you label it a beta (as perhaps Apple should have done with Mobile Me), they know how to take appropriate precautions so that when terrible things happen, it doesn’t wipe out their data. Free and open source software developers can use and test your software in ways that the average user can’t or isn’t interested in doing.