Posted on

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!

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.