Grants, bounties and free software

Bounties or grants are often suggested as a way companies can pay for work on free software projects.

The GNOME community has had mixed results with bounties and grants, so when Funambol community manager Stefano Maffulli contacted me about a GNOME grant and said they'd had success using grants for Funambol, I thought it'd be interesting to learn more about the program.

Here's how the Funambol Code Sniper has successfully used grants to foster research and development efforts in free software projects. The responses are from Stefano Muffulli.

People have mixed opinions about grants or bounties as they are sometimes called. What has been your experience?

2368673742_a0da965a88_o I consider the Funambol Code Sniper program to be our networked research and development effort. Being a commercial open source project, Funambol needs to respond to customer requests first and at the end of the day there is little time for exploration. Therefore, sometimes it is more convenient to empower teams that are not part of the company to explore environments that are not necessarily going to generate revenue.

For example, under the Code Sniper program, we sponsored a solution to sync contacts with Yahoo! and Google services long before we had any customers ask for it. Now that code is part of the Funambol commercial offering (and we've hired the developers, too).

Another example of this R&D play is the exploration of social networking features that resulted into the development of AvatarGrabber: it's a simple java app that 'scrapes' the web in search of images of people in your addressbook and lets you chose which image to assign to them. The result is a 'pimped' addressbook with your friends' pics from myspace, facebook, gravatar and other sites. We don't know yet if this software will ever go beyond being a cool toy and end up in a product but nevertheless the company has learned something about social networking from it.

We haven't had any backlash about offering cash bounties. We do recognize that free software developers are not really motivated by the money aspect, and that it's something else that makes them tick. However, we view the money as a token of our appreciation for their effort, to recognize them, and they can always donate it to charity or some other cause if they don't really want the money.

Do you attract new developers or existing developers?

The people that participate in the Code Sniper program are mostly young developers willing to learn how to develop for mobile environments. They're not complete newbies, though: mobile software development can get pretty complex.

Do people that work on the grant projects usually stick around and work on other projects, paid or unpaid?

Several of the participants in Code Sniper have been hired. The rest are still maintaining their projects as volunteers.

Do you get a lot of good work this way? Are you able to take the code the grantee gives you and run with it?

For the majority of the projects, we end up with decent code, at least for a proof of concept. But mostly we gain experience as a company: we try to make sure that all projects have an internal mentor that can devote a few hours per week to follow the project so that at least one team member can participate in the development process. Occasionally we don't get good results, mainly because of lack of communication between the code sniper and the company or even the wider community.

Do you close the grant as soon as one person says they are interested or do multiple people work on it at once? If so, how do you decide who gets the money?

We've had cases where more than one person applied at the same time for the same grant. In those cases we try to encourage collaboration with the candidates and split the grant equally. In our experience this is not an ideal solution though.

To improve the Code Sniper process, I'm working to change how the incentives are distributed. The new process will reward the constant effort from the participant and allow for more people to work on one project without conflict.

I'm also thinking of other non-monetary compensations, like kudos or Linkedin recommendations from our lead developers, donations to their favorite .org and so on.

One complaint against grants and bounties is that by the time you finish specifying the requirements, you might as well have written the code. How much work do you spend getting the specifications right?

We do very little of that. Usually the grants are just basic ideas and we leave to candidates the chance to elaborate further and shape their own project.

The candidates need to send a brief resume and a very basic draft project. After approval, they're asked to write the full specifications of the project and discuss it with the Funambol developers on the mailing list. Once the specs are ready, the (fun) development phase can start. When development is done, a first half of the grant is paid and the software is tested by Funambol engineers. If they consider the project done, the other half of the grant is paid.

I'm investigating whether it would make more sense to use a 'leaner' approach to development, with less planning in advance and more coding. Unfortunately I still haven't found the appropriate balance between free software coding habits (unregulated scratch-your-own-itch) and lean development techniques like Agile/SCRUM (that need a management structure and role separation between users, product owner and developers).

If your readers have any pointers to material, I'd be glad to learn more.

How many successful grant projects have you had?

The Code Sniper program was started over 2 years ago and the company is satisfied with the results obtained so far:  4 components developed with these bounties have been integrated into the Funambol product and are shipped to customers, one of these helped acquiring a new customer. A few others are being considered for inclusion in the product (like the Funambol client for Mozilla Thunderbird).

What are you most excited about the Funambol Code Sniper program?

I like two things of this program: one is to see this program as part of a larger free software innovation network, especially useful in the mobile market. But mostly, it's exciting to be able to give back to the free software community.

Thanks, Stefano!

Open source is (still) changing the way work gets done

[The beginnings of a keynote. Feedback and input welcome.]

Open source is changing the way work gets done. Yeah, yeah, what's new? We all know that. But really, free and open source software has changed the software industry in the past but it's really changing things now. Especially when you look at industries that are now using open source software that didn't used to be in the software business: cell phones, netbooks, medical equipment, …

Once upon a time …

All software was free. Nobody thought software was worth anything. It was the enormous, huge machines that were important.

Then one day people realized that software was important. And since it was important and perhaps useful, they could charge for it. In order to do so they had to hide how it was done or everyone would just copy what they did and not pay them.

It was Richard Stallman who pointed out that by not sharing how it's done, we severely limit ourselves and how fast technology can grow and benefit society. (He compares it to music – Mozart and Beethoven couldn't have written their music if we copyrighted notes. I first heard him speak about it at GUADEC 2001 in Copenhagen.) And he wrote the GPL, one of the most popular free and open source software licenses.

It took a few years, but finally people caught on in a big way. The world got to hear about Linus Torvalds' Linux project. And people went on to write all sorts of useful software projects – under free and open source licenses.

And then, when it became apparent that this free stuff was useful, people started wondering (once again) how they could make money off it. They came up with a few models that have proven they work.

  • Support & Services
  • Proprietary add-ons
  • Dual licenses
  • Hardware enablement
  • Advertising

And for a while it looked like that was going to be it. Open source software provided lots of inexpensive, great technology for individuals and companies. It saved them not only money but time. It enabled them to go to market faster, with more flexible technology, that met their needs or their customer's needs better, and it was often more secure and robust to boot.

And it changed the way the world worked. At least the technology world. I believe that much of the technology we have today has moved along much faster than it other wise would have either because it was open source software or because there were open source alternatives. I think netbooks owe their existence to free and open source software. One Laptop Per Child showed that you could make a cheap laptop and when the more traditional hardware vendors went to match it, they discovered that they could meet those low price points with free and open source software. (And then Microsoft had to match those price points to stay competitive.)

And developers have much better jobs these days because they have access to the open source development models. It's now common to be able to search bug databases, report problems, post code, try out other programs that might solve parts of the problem you are trying to solve. (And these aren't necessarily all due to open source but open source made them standard, made them the expected way of doing things.)

And then the big change.

Open source entered into businesses that weren't even traditionally software businesses.

Take a look at the mobile industry …

I went to the open source in mobile conference in Berlin last year and I sat next to some people that were at an open source conference and they didn't know what Linux was. (They didn't know what GNOME was either – it was in explaining what GNOME was that I realized they didn't really know what Linux was either.) These people are entering the open source world for an entirely different reason than companies have in the past. They aren't trying to make money off of open source – they might think they'll save some money – and they aren't trying to create an open source business model. They already have a business model. They make cell phone hardware or they provide phones and services to end users or they make applications for cell phones.

They are in open source because it provides the technology they need to make their business happen. What brings them to open source? It's flexibility, it's time to market, it's not reinventing the wheel but yet being able to customize their offerings for customers. It's a lot of the same things that originally made open source software attractive to enterprises but what's different with these new users is that they often become developers not just consumers. They need to make Linux or GNOME Mobile work on their chipset or their handsets and they need those changes to go upstream. And they are used to just asking their suppliers for the change, not negotiating with a project that includes a bunch of their competitors.

So far, the people I've worked with have been really excited about working in open source but there's no doubt that it's shaking up the supply chain.

How does a netbook vendor, one that's typically just manufactured hardware and worked with Microsoft for the software, how do they go about putting free and open source software on their hardware? Do they partner with a Linux distributor like Red Hat or Novell or Canonical? Or do they partner with a company like Intel who's come out with a whole new interface for netbooks, Moblin? Or do they hire a bunch of developers (or hire a company) and come up with a new interface just for their hardware?

Are the mobile devices of the future differentiated on hardware, operating systems, interfaces or applications? Or service plans? (I think the answer is yes, all of the above.) And open source enables them to compete effectively in all the software components (operating system, interface and applications.) It gives them all the building blocks and enables them to create custom solutions that meet their customer needs. And they can focus on the customization, not the building blocks. But open source also makes it harder. You can't just make an interface and deliver it to customers and say "here's what you get." Now customers expect much more, and they expect to be able to download applications, and get software updates on the fly.

And it's not just affecting mobile – it's affecting all technology. Look at medical equipment. It used to be that every medical equipment provider had their own proprietary software that ran on their own proprietary hardware. Now companies like Supersonic Imagine are using open source software technologies, like GTK+, to build custom software that meets their customers needs.

And GPS manufacturers are using open source components.

And digital video recorders and printers have open source components in them.

And all these companies and all these developers are now working in a collaborative world-wide environment. These are developers who we never used to see. We never saw their work or got to benefit from what they did. (Except people that bought their products.) Now all those developers are part of a greater ecosystem. And the changes that are made to a product to make it work well for GPS's also benefits netbooks. And servers. And web apps.

It's bringing collaboration to people and companies that aren't even in the same industry.

To give you an idea of how far reaching the same open source components can be: there are GNOME  technologies … In phones. In GPSes. In medical scanners. In Moblin. In netbooks running their own interfaces – Eee PC's are built on KDE but have GNOME technologies in them as well. And all of these people and industries are collaborating on the same software!

Universities have responded to this by using open source software projects in their classes in order to make sure students have the skills they need to collaborate effectively.

For example, Emmanuel Fleury, a professor at Bordeaux University, is using open source software projects as a learning ground for students. He has students fix bugs on real projects. They learn how to read code, work with the community, interact with existing code … all skills they'll need when they start writing code at their first job.

And universities are using the open source model and value system to attract a new type of student to programming. The HFOSS program, run by Ralph Morelli and Trishan de Lanerolle at Trinity, has successfully attracted more students to computer science, and more women in particular, by focusing on open source projects with humanitarian causes. During the summer they bring students to the campus, teach them and put them to work on a portfolio of open source projects with humanitarian causes. Community members from the project serve as mentors. The students get housing and a stipend just like they would at a traditional internship at a software company.

These students will start their first jobs with real life experience. And contacts. And a reputation they can build on and call on. And when they leave that job and go to another, they'll take their experience, their reputation and their roles along with them. And their networks. 10 years ago I knew a bunch of software developers at HP, where I worked, and that was pretty much it. I knew people at our customer sites and I knew friends from college, but I didn't share technical problems I ran into with people outside of HP. I didn't share the cool things I wrote with people outside of the company.  Now, developers in jobs like that work with developers around the world. Their networks, while probably still mostly people in their company, now include experts from different projects around the world.

Developers in the mobile companies I talked about are working on
the GNOME Mobile mailing lists and in the GNOME projects with freelance developers, developers from their own companies, developers from competing companies and developers from all up and down the supply chain from chip manufacturers to carriers. And that results in happy developers, more integrated products, complex products that get to market quickly and in lots of very cool options for end users.

OpenSUSE Community Week

OpenSUSE is holding a community week this week, with a GNOME track. Curious as to what that really means, I asked Vincent Untz and Zonker (Joe Brockmeier) some questions. I really like that open source projects often find really new and effective ways to get things done.

There's a openSUSE community week going on right now, what is a community week?

Zonker: Our community week is a chance for experienced contributors to help pass on what they know about packaging, translations, testing/QA, and so forth to newer contributors and mentor them a bit to help them get started. It's also a chance for people to just pop in and meet with a lot of contributors to learn more about the project and ask general questions about the openSUSE Project.

Vincent: It turns out that there are many people out there who are interested in helping but they just don't know how they can help. This is where the community week is really helpful: we introduce people to the various activities that are handled daily by various teams, and we show them how they can contribute to this activities.

How do people join?

Zonker: In the various IRC channels. There are separate channels for the GNOME team, KDE team, marketing team, etc. You can find them all here: http://en.opensuse.org/Communicate/IRC

How many people are participating?

Zonker: Hard to say. We've about a dozen openSUSE contributors who will be leading sessions this week, and more who've helped with setting up the schedules and recruit people to lead sessions and so on.

According to the Facebook page we already have about 100 confirmed attendees, and I'm pretty sure that not all of the openSUSE contributors and new contributors use Facebook, so I'd say it's well more than that. Looking at the IRC channels today, I'm seeing quite a few nicks in IRC that are new. I'd say by the end of the week we'll have seen hundreds of people join in sessions across the various topic
areas.

Vincent: Just a (random) data point: in #opensuse-gnome, we generally have around 60 people. When I looked at some point yesterday, we had 80-85 people. That's +33%, which is quite good. Also, it's IRC, so we get people joining and leaving at all time of the day 🙂

Of course, not all of the new faces have time to contribute, but they are able to learn more about the community this way, which can only be a good thing.

(oh, and the not-so-new faces — people who were already on IRC before the community week — are also contributing too)

Are they still working or did they take the week off?

Vincent: It really depends on the people — some people are investing some of their free time at work, some are not working (students, or people taking vacation). And then we have some interesting cases like Christopher Hobbs: he'll lead the GNOME Bug Day on Friday, and I believe his employer lets him handle this specific event on his work time.

Zonker: For Novell employees, this is part of the job to engage with the community, so I'd have to say "still working," but people doing Community Week should be doing this as part of their normal work. Not all the topic owners are Novell employees, so I can't say whether our other contributors are taking time off or getting time off to do presentations.

What type of work gets done during community week that doesn't normally get done?

Zonker: Primarily, a lot of mentoring and teaching. It happens other times, of course, but this is more of a focused effort.

Vincent: I can confirm this. Based on the past two days, the main difference is that experienced contributors take more time to help newcomers, and newcomers ask more questions.

What are you most excited about so far?

Zonker: We seem to be getting a fair number of participants so far, so I'm excited by that.

I'm also surprised, but probably shouldn't be, at how many groups are jumping in and setting up sessions of their own — the Samba team, Education team, and the openSUSE Weekly News folks have already
volunteered to do sessions though those topics weren't on the original schedule. Which is, of course, awesome. The more the merrier!

Vincent: One thing that really strikes me is that people are willing to learn. It's not something new, but it's really good to see people curious about things, and experimenting, asking questions, etc. to learn the right things to do.

Also a really good surprise is that the Thunderbird people are planning a Linux testing day this week and coordinated it so it ends up the same day as the GNOME testing day of the community week. So we'll have packages of the latest thunderbird code for people to test. I didn't expect some cross-project effort like this, and I'm quite excited about it 🙂


What's in store for rest of the week?

Vincent: On the GNOME side, we'll have some wiki space reorganization, but most importantly we'll have a testing day on Thursday where we'll get feedback/bugs from people on various features or applications (thunderbird, multiscreen support, probably pulseaudio, also hopefully the new at-spi-dbus code that will be the basis of GNOME 3.0 accessibility, maybe also gnome-shell, etc.). Then we'll have a bug day on Friday where we'll triage the GNOME bugs filed against openSUSE, and forward all the relevant ones upstream.

And of course, people seem to want to package applications, so this will be an area where we'll keep helping people! We plan to have more volunteers this week-end to help mentor, and so we'll see quite some action on Saturday and Sunday in #opensuse-gnome!

Zonker: We have a lot more sessions for packaging, testing/QA,
GNOME, KDE, marketing, and openFate will all be on the schedule. The
openSUSE Board will be holding several sessions Wednesday and Saturday
to meet with contributors and answer questions about the board and to
get
feedback.

Zonker:  You can find each of the schedules here: http://en.opensuse.org/Community_Week

There's still time to join them!

A call to support open source software projects

Many of you saw J5's call to support the GNOME Foundation. The initial response has been great! I wanted to follow up with a general call to support open source software projects financially.

The GNOME Foundation is a 501(c)(3) nonprofit. By definition it must serve the general public and by definition it must be supported by the general public.

Our charter is not to be supported by a small subset of companies, but to be supported by a large group of companies and individuals. Remember 501(c)(6)'s are trade groups and are supported by a group of companies. Their charter is not to help the general public but to help the business of their group members. The GNOME Foundation is a 501(c)(3) – which helps the general public. 

The GNOME Foundation has been lucky to have a group of companies that support us financially. With their help we've been able to do a lot of good things over the past 10 years. We've had annual conferences, hackfests, and programs like the accessibility outreach and women's outreach programs. And while a number of companies have expressed their interest in
joining the GNOME Foundation and supporting us financially, the reality
is, very few companies are adding anything to their budget this year.

But compare the GNOME Foundation's financial support from 12 companies to the FSF's model.

The FSF receives most of its funding from 1,000s of individuals. According to their 2007 tax forms, they raised $845,000 from the public. (That number probably includes companies, but it's mostly from individuals.)

That is a much stronger position to be in. Not only because they raised more money, but because they are supported by the many individuals.

Open source software has shown the strength of individuals in creating great products. In the FSF's model, they have also shown the strength of individuals in being able to financially support causes they believe in. Providing your own financial support enables you to do what is right for your project. (Companies don't prevent us from doing what is right. But when they provide funding, they set direction. For example, when we depend on them for funding for hackfests, we hold the hackfests they are interested in sponsoring. Luckily, they sponsor good things! However, there is much more we could do, like the GTK+ hackfest we wanted to have this year.)

Bradley Kuhn and I were talking at the Collaboration Summit and we were thinking we should have a campaign to encourage open source software fans (users and developers) to support open source software financially. Pick two projects, any projects, and support them. Here's a short list of some projects that are set up to receive donations and use the money to support their projects:

In addition, I'd encourage people to sign up for "subscription" plans. Having regular donations come in helps projects plan things.

I have a few more posts coming up:

  • Voice your opinion of how money should be spent. For example, voice your opinion on the mailing list when the budget is shared or when the call for plans goes out. (And if you aren't in favor of donating money to free software projects, share ideas on how things can be done with no budget or which things you'd like to see cut from the budget. Or how you'd like to obtain the money.)
  • Participate in your project's non-code plans:
    • In GNOME's case, become a member of the Foundation and vote for people that support your positions! Not only is your vote very important, but having a strong membership helps the Foundation show what it has to offer when discussing our technology and our plans with potential partners and sponsors.
    • If you have the interest or skills, join the GNOME marketing team – help create our messages to the general public or run campaigns like Friends of GNOME or a merchandising store.
    • Speak about free software, why you believe in it and your project to the general public as well as at open source events.
    • Help your friends use open source software. Don't push them but be there to help them install it, even if it's just one application like GIMP or OpenOffice. If it works well for them, they might come back and ask you for others. Encourage them to contribute (skill or money) if they have a good experience.

And of course, continue to write great code and create awesome free software projects!

Which projects will you support?

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.

Dries Buytaert’s rules for creating a great community

Dries by PluggConference2009, http://www.flickr.com/photos/pluggconference/3349434040/
At OSBC last week I saw a great presentation by Dries Buytaert on how to build community. Dries is the founder of Drupal. The slides for his presentation (20 MB) include "Dries' 7 secrets" which I'll write about here.

Dries started out by showing us how the Drupal community really is a community excited about Drupal. He had pictures of people carrying around cutouts of people that couldn't attend a conference, hand made Drupal socks, Drupal cookies, etc. He then went on to give his "rules" for creating community:

  1. Open source communities are always a bit broken … and that's good. You have to learn together and grow together in order to become a community. Everything won't be perfect and that's ok.
  2. Software architecture should be modular. By having a modular project you enable people to write their own module, use your product and avoid forking. So you can say no to them and they can still write what they need. He also advocated for keeping all the software, including the modules, centralized in one place.
  3. Put community in control. By having them own their own modules, you empower them. He also said "screw roadmaps", they kill innovation, just let people work on what they think is right. TRUST = currency. Make trust flow and you empower folks.
  4. Tools. Make sure you have community design patterns. By design patterns he meant tools and processes that allow new members to join easily, create a sense of id (avatars, pictures, etc), converse (forums, blogs, etc), support (forums, bug tracking), etc. Make sure you have the tools to create a successful project and community.
  5. Mission. Find a higher purpose that your project can serve. Chase the dream, incite passion, rally people both community and customers behind your purpose. (FYI, GNOME's mission is to provide a free desktop to all regardless of ability, financial circumstances, or nationality. Free access to the desktop, to technology for all.)
  6. Culture. Make sure it's 100% transparent and one of collaboration, sharing and helping. Do everything online, avoid private conversations, all decisions are public. Be authentic, be honest. (The topic of doing everything online came up several times. Josep Mitja from Openbravo said that their employees sit in the same room and have their meetings on IRC so everyone can participate.)
  7. Leadership. And leadership is not management. Telling people what to do does not create a movement. Instead get people together and get out of your community's way. He quoted Clay Shirky "Replace planning with coordination." As an example, he talked about how before cell phones people had to plan meetings, whereas now they can just coordinate where they are. (FYI, I got the impression he hadn't planned many meetups before cell phones. Having just traveled to a part of South Dakota where my phone doesn't work and trying to meet up with tons of family members, I now realize just how much we rely on coordination instead of planning.)
  8. Join your own community! As a peer! This was a bonus rule but one Dries said is often over looked. This also came up during the community panel I put together later in the conference. You can't give special status to your employees. They need to join the community like anyone else. Dave Neary had an example where the boss said he wanted to give employees everything they needed to get the job done, including commit access, and Dave had to explain they needed to earn it like everyone else.

Dries was a passionate speaker, knew his stuff and had great visuals to go along with his presenation. If you get a chance to see him speak, I recommend it.

Any other rules you'd add to Dries' 7 (or 8) rules for creating communities?

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.

Open source enables companies to collaborate

Dave Neary gave me his speaking slot at OSiM USA. I have two challenges, make a talk to fit his title and abstract (although you can almost always safely ignore the abstract) and give a good talk in 20 minutes of time. Here are some thoughts I have. (The title of the talk is Increasing Ecosystem Collaboration through Open Source but I'll let Dave blog that talk.)

Open source software has proved that collaboration between individuals, regardless of geography, time and management structures, can work really well. The open source software model works:

  1. Self motivated. Open source software developers get things done. They don't need to be reminded of what's important or how much work they should be doing.
  2. No management. There are no managers in open source software. There are leaders but people don't work for a manager who tells them what they need to work on first. (A friend of mine once worked all weekend on a customer problem only to have his manager tell him on Monday that if he was going to work all weekend there were other things he should have been working on!)
  3. No time clock. Nobody cares if it took someone 10 minutes or 10 hours to write that patch. They just care if it works and when they can get it.
  4. No performance reviews. There's lots of peer review and lots of feedback – perhaps more than anyone wants – but there are no annual performance reviews tied to raises and promotions.
  5. Fast. While it may not always seem so, things get done very quickly in the open source model. Someone has a good idea and they just do it.
  6. Bad ideas die. On the other hand, bad ideas just die. Nobody keeps pushing for them – or if they do, they can't get other people to waste their time on it.
  7. Evolves. Ideas and projects in open source software evolve as the world changes and new people join the project. (And nobody is paying big money to keep it the same.)
  8. Work gets done. Even without anyone telling them how to do it and what to do, work just gets done.
  9. Communication is great. While it may not always be friendly, communication in an open source software project is great. Everyone knows who is doing what, what decisions have been made and everything is publicly disclosed and documented. In a completely virtual and global environment. If communication isn't great, the project usually doesn't last.

Some companies have figured out how to work well with open source software. Now we need companies to figure out how to work together in an open source way. While some companies have figured out how to work together, either through consortia or through their employees that work on the same open source software projects, others are still figuring out how to collaborate and still keep a competitive advantage. Open source enables companies to collaborate.

Take GNOME Mobile. Many companies are working together, producing very different products, all built on GNOME technologies that are being adapted to new mobile devices. They collaborate on the technologies. On their ideas. And avoid reinventing the wheel. Not only are they using existing GNOME technologies, but the changes they add to make it work well in a mobile environment (whether it's netbooks, scientific devices or phones) and can be used by others who share the burden of maintaining and developing it. Without losing their competitive edge.

So how can companies get involved and cooperate with other companies effectively?

  • Join any consortia or group related to your project, like GNOME Mobile and the GNOME Foundation. This is a good first step as it enables you to meet all the players and often you can find friendly mentors and people to help. Sometimes this is as easy as joining a mailing list. Other times it means paying a membership fee or going to an in person meeting or a conference.
  • Join the discussion. Join the mailing list, irc channel, comment on blogs. Listen and participate. Become part of the community. (You might want to do this before you officially join.)
  • Hire developers or contract companies. Open source software works because lots of people work on it. You'll get a lot of good stuff for free, and people will be glad you are using it, but you'll want to have some technical resources to fix a particular bug, add a specific feature or adapt the open source technology for your product.
  • Use the software! Use the open source software out there. By using it, asking questions, suggesting changes, you'll become part of the community.
  • Let people know you are using it. Several of the products using GNOME Mobile technologies have never told us. We've "discovered" them. We'd be more than happy to work with them.

Any other things companies can do? (As people who have seen my more recent talks can attest, I use the ideas people leave in comments. Thanks!)

5 types of company open source relationships

Companies and communities is a topic I'll speaking on at SCALE. I welcome any feedback or points to consider!

First off, there is no ideal company/community relationship. There are lots of different types of relationships between companies and the communities they work with (or don't work with) – and no one way is perfect for everyone.

The goal should be for companies and individuals who use and support open source software to work effectively together. And part of working effectively together means making sure that the open source model is sustainable. Which means interacting for the good of the project, not just taking or using open source software.

However, how best to interact with the community is a question that many companies struggle with.

It's easy to give companies some general advice: be transparent, let
your employees contribute, talk about what you are doing, … but a
good advice has to take into account what the company is trying to do
with open source software.

In this post, I just want to enumerate some of the types of companies that interact with open source software.

I'll use some of the companies in the GNOME communities as an example because I think GNOME has good, strong ties with the companies in its community.

I can define the following types of companies. There is some overlap between categories.

1. Companies that just use open source software products. These are companies that use GNOME software in their company, say as their desktop or as their image editing software. People use GNOME and they are part of our community whether we talk to them regularly or not. They test the software, do word of mouth marketing, and add credibility to the project among other things. I wrote a whole article about The Role of Consumers Within an Open Source Community. You could argue that a company full of users might have more responsibility to the project than just an average user. And some do. We sometimes get financial support, great case studies and references from companies that use GNOME.

2. Companies that distribute GNOME. In the case of GNOME, some of these are obvious, like all the Linux distributions. Others are not so obvious, like devices or phones that contain GNOME technology. There are also several categories, those that modify the open source software product and those that don't. In the case of GNOME, I think many of our distributors modify it before they ship it. These companies bring some obvious benefits like developers working on the project, fixing bugs and adding features. They also bring some less obvious benefits like ties to end users, marketing, and financial support. The best companies figure out how best to "work upstream." Working upstream means working close to the project, getting your fixes and contributions accepted and into the main branch. For many companies, that is really hard. They often have to make a lot of fixes to make a product acceptable for their solution or their customers and by the time they have time to check it in upstream, they're a version behind and the project doesn't want it. The best companies figure out ways to minimize that time warp.

3. Products built on or with open source technologies. These are companies that build products like Nokia tablets, Garmin GPS units or Supersonic Imagine (the breast cancer scanner). Some fall more into the user category than the distributor category (although they do both.) They need to make sure their developers establish relationships with the community, at the same time they make sure that their companies also establish a good reputation for being supportive of the open source software products they use.

4. Creators of open source software products. There are more of these than you'd think and they fall into lots of different subcategories. Products like Banshee where the key developers work at Novell or products like Maemo started by Nokia but working on creating an external community. These companies need to decide whether they want an external community, an independent community or if they just need an open process for their project.

5. Services. Companies offering services or contract development work around an open source software product. In the GNOME community these are companies like Fluendo, Openismus and Codethink. These companies often have strong community ties because they hire contributors or their employees quickly become contributors.

Any other types?

12 tips to getting things done in open source

Most people used to the proprietary software world, with no experience in open source software, are amazed that anything gets done. (And lots gets done in the open source, way more than in most proprietary software companies!) And people new to open source are usually at a loss as to where to start. Often they come with a great idea, tell a couple of people who confirm it’s a great idea, and then … well, and then they don’t know what to do and the great idea fades.

So here are some of my ideas on how to get things done in the open source world. And I am by no means the expert – I’m in awe of some of the people I work with on a daily basis.

To get things done in open source:

  1. Be prepared to do a lot. Somebody has to do it. And while you can convince others it’s fun and needed and great, if you aren’t willing to put time into it, why are they going to believe you?
  2. Believe you are empowered to do it. If you propose a new idea and everyone tells you it’s great, believe them. And just do it. Nobody is going to say “ok, now you can do it.” If people give you positive feedback, take that as an ok to go ahead.
  3. Recruit others early. The earlier you talk to others about your idea, the more likely they’ll be able to contribute to the idea and feel like it’s theirs. The more they feel like it’s theirs, the more likely they’ll contribute. Most people hate to share an idea until they are sure it’s a good idea that’s completely thought out. By that time, it’s your idea to be done your way and it’s too late for them.
  4. Don’t worry about getting credit. It’s all done publicly, on a mailing list that’s recorded for prosperity or on IRC in front of everyone. You’ll get your credit. Float your idea, encourage others, accept their feedback and ideas. Give more credit than you take. (And ask yourself if you want your idea to happen or if you want credit. Either answer is ok but only one can be your highest priority.)
  5. Join the conversation. Many people float an idea via email or maybe even on the mailing list. Where probably depends on the project but there are conversations happening some where. I think the one most missed by those new to open source software is IRC. I once heard a manager joke that nobody hangs out around the water cooler any more. Instantly someone mentioned (on IRC) that IRC is the new water cooler and he just didn’t know it.
  6. Get effective at monitoring lots of information. In my experience, people in the corporate world spend a lot of time talking about how they get too much email (I did) where as people in the open source world (at least GNOME) spend their time talking about methods for dealing with lots of email. It’s way cooler to be seen as someone who copes with tons of email than someone who gripes about tons of email.
  7. Reply to all. I worked on an open source like project with some people that weren’t familiar with open source. I got so frustrated with people that didn’t hit “reply to all”. I spent a lot of time recommunicating decisions and we didn’t have a lot of conversations that we should have had.The project had a lot less “team” because people didn’t reply to all. By “team” I mean people didn’t feel part of a team and they didn’t have all the information they needed. Also, one of the strengths of open source is that all of the history is in the mailing lists. If you don’t reply to all, your project will lose that advantage.
  8. Think the best of people. Things get lost in email. It’s much easier to misread an email or take offense at something in an email than it is in person. Remember this whenever you get upset at an someone because of an email.
  9. Meet people. Along the same lines as communicating well in email, meet as many of your fellow open source people in person. This is somewhat controversial as the open source model works really well in a virtual world. But I think that conferences like OSCON, GUADEC, SCALE and OpenSource World that get lots of open source people together, create stronger relationships and better projects. Personally I find that when I can read an email in someone’s voice, it makes a lot more sense. It’s often funnier and more relevant.
  10. Be yourself. Be yourself, add some personal notes, make sure your motivations are transparent. Anyone who is obviously acting with “ulterior” motives – like pushing their company’s policy without thinking about what it means to them and the project – is less trust worthy. Not because what they are doing is bad but because it’s hard to know what type of decisions they are going to make and carry through on.
  11. Ask for help. There are a lot of people in the open source community willing to help. Just make sure you share the whole plan and ask for specific help. If you don’t share the plan, they won’t know why they should help. If you don’t ask for specific help, they won’t know how to help.
  12. Show your passion. Excitement is contagious. Share why you are doing what you are doing and why it’s important or fun. (Be sure to temper the “because the alternative sucks” viewpoint.) Be positive and passionate!

What else would you add? What’s your best tip for getting things done in the open source world?

For more detailed ideas for how to actually get the work done, see 10 skills to master to get things done online.