Collective funding, design and development of Drupal projects

abbood-gdo's picture

I would like to raise a discussion about the prospect of the Drupal community using a system that allows collective design, funding and development of any Drupal project.

Think about it this way: if the Knight Drupal Initative is the Google summer of code for Drupal, what I'm proposing is a Google year of code for Drupal, only there is no single entity such as Google or DKI funding projects, the funds come from community. My partner and I have already implemented a solution that makes that possible ( I would like to hear from you about how suitable this model is for the Drupal community at large.

In this model, the community would also collaborates on the design of projects, and most importantly on the development of the projects: projects get split up into smaller sub-projects, and the funds also get split up amongst those sub projects as well.

The point is that the barrier of entry for anyone to take part in the design, funding and development gets much lower: you can donate as little as a couple of dollars (but dollars add up), you can assist in refining design without committing long hours, and you can develop a small piece of code and get paid for it.

There are a lot more details to discuss. But if you like to find out more the system is already up and running, you can check it out at My partner, John-Paul Gignac and I are behind this initiative. FOSS Factory is a for profit organization, however our mission is to accelerate the advancement of open source software. We are more interested in that than in making money (and so is our angel investor). In fact, all of FOSS Factory is open source and available for download (

What would like to know here is that is this system viable and does it add value to the project creation process in Drupal. If so then how is the best way to use it? Is it best used externally (as in using or is it best implemented within (perhaps as part of the drupal site redesign effort by Mark Boulton and crew). We don't mind at all in fact we would be happy if the Drupal community takes the code in implement it within their site (we open sourced the code for a reason). What's in it for us is that we can learn from the experience, gain exposure (We can use Drupal's acknowledgment), refine the system as Drupallers use it at a mass scale, and finally offer it as a service for other open source communities that don't have the coding power or the community support that Drupal does.

Looking forward to hearing from you!

Abdullah Bakhach


Need more structured and transparent funding model...

dahacouk's picture

I am very much in favour of the model that Abdullah proposes. In fact I proposed it myself way back when:

I reckon it would be far more effective if this system was integrated into d.o rather than an external system.

There are many people who would give cash into a central pot or individually for specific module/core development if there was seen to be a more transparent and equitable funding model and funding tracking system. There are so many users crying out for development and very willing to pay for that development.

Don't get me wrong. I love the open, pretty flat and non-hierarchical (?) way that development currently takes place. I'm not suggesting that this changes. I'm suggesting that better tools are created to track funding requests and offers. This needs to be more database like and less like the forum we have now.

A "developers time is precious". We need to make the whole process of funding developers slicker and more transparent. When I and others can see what's going on with our cash I believe there will be enough to take Drupal to the stars. Cash will come flooding in. But we need the mechanism to observe, track and manage this process. When we trust it I and others will give.

The objections I have encountered from other people I have spoken to - and they are not trivial - are...

  1. "If we make it too easy for end-users (non-developers) to request and pay for new features (and effectively "call the shots") could this steer the project off course - away from beautiful code and quality interfaces?" For example, I could just pay for Add Display Name field(s) to core in addition to Username even though it's seen as not appropriate in core.

  2. "We could get the Debian effect where some developers are paid and some are not." But Debian survived, didn't it?

I look forward to other comments...

Cheers Daniel

Integrated into vs. external

ajlowe's picture

I met Abdullah at Drupalcon on Sat. We spent a couple of hours looking at the details of his site, discussing how it fits with Drupal and having Hungarian goulash. I think FossFactory has the right idea about how to do bounties in a fair and efficient manner. There are a few rough edges, but it is a new project, and he seems to be focused on benefiting the community and improving the site / concept.
If the Drupal community decides to use FossFactory, I think the best way is to simply link to a Drupal section of instead of trying to tightly integrate it into for a couple of reasons. Most importantly, I think FossFactory is still in development and will be adding features and benefits for the foreseeable future. If we take the current code and integrate it into D.O, we will always be running an older, feature poor version, and we will have to support / maintain it. Why not just link to FossFactory and be done with it? Another reason is to provide exposure for Drupal. If developers see lot's of paying Drupal projects on FossFactory, they might decide to be Drupal developers.

I agree with Daniel that a more transparent payment system would be ideal, but I caution that exposing more details makes it easier for bad people to "game the system." Transparency and detail is the right way to go, but proceed with caution and forethought.

As for Daniel's objections:
1. I don't see much risk of steering the project off course. The purpose of Drupal is to provide solutions to the end-user and no one votes more honestly then when they vote with their wallet. Our job as developers is to guide end-users into the correct solution for their needs, not to tell them what their needs are. I am confident that the current Drupal leadership will continue to act as a gateway for good code and good concept.

  1. We are there now. There are hundreds of developers getting paid to code for Drupal. There are three paid developers just for Ubercart and we are hiring. (If you want a job, PM me :) In many cases the only difference between a paid developer and a volunteer is whether they are doing what they love at home or at work! Using FossFactory will expose and publicize that people are getting paid, but I don't think it will cause people not to volunteer. In fact, I think it will help the volunteer community by showing a clear path to go from volunteer to paid. Currently if you want a paid Drupal job, you have to do a large amount of volunteer work in order to get enough "street cred." to get a full time job. Something like FossFactory will break that large jump into smaller steps. FossFactory will make it easier for Development shops to find developers and vice verse.

Just some thoughts. . .

Help organizing funding for events?

robertDouglass's picture

Interestingly, fossfactory is close to an idea that I tried to implement once upon a time. Good on you for seeing it through!

Could Fossfactory be a tool to help run regional "Camps" or "Cons"? I don't want to have to start my own non-profit just to do DrupalCamp Cologne. Any ideas?

Understanding Social production and the Drupal value chain

Amazon's picture

I want to thank Abdullah for posting here, we discussed this proposal at some length at Drupalcon Szeged.

This economic model is a classic contractual model of production. It includes time, materials, open market place, collective funding, transparency, etc. But Drupal development does not rely on this old school economic model. Drupal development is part of a new model called social production based on a new social framework.

Where as the old model relied on constrained resources of electricity, communication, and production facilities the new model relies on creativity, experience, and wisdom. The social framework which Drupal is developed on interesting problems, talent, motivation(frequently not cash), social relations, and social exchange. The Fossology model does not include these components of the social framework and is therefore incomplete. But that doesn't mean it is mutually exclusive with Drupal development. We just have to understand and recognize it's limitations.

The second thing that must be considered is the Drupal value chain. In previous surveys we've seen 80% of respondents are site owners and 20% are Drupal consultants. Most of the value derived comes not from individual stand alone components but the ability to ensure a full functioning Drupal site which meets a higher goal. The economic model of Fossology does not capture enough of the value chain and therefore will be under a lot of competitive pressure from these folks:, and these folks who have strong ability to generate value. For example, any half decent Drupal developer has been swarmed with job offers over the last few years.

The introduction of Google Summer of Code and Knight Foundation Drupal Initiative funding are good barometers for the effectiveness of the market for discrete funding of Drupal functionality. I am keen to see what alternate ideas are proposed for this model.


Drupal community adventure guide, Acquia Inc.
Drupal events, redesign

The debian effect and steering projects off course

abbood-gdo's picture

Thanks for your support Daniel. My response to the second concern you raised is to simply look at FOSS Factory as a market place for ideas, capital, and talent.

Good ideas would draw even more ideas from the community to refine it, it would draw their funds to fund it and it would attract developers to work on it. Think of it as resource attraction rather than resource allocation. Resource allocation is what Canonical did by hiring some Debian volunteers and ignoring others. In FF's case no one gets hired, developers get paid only when they submit code that meets the requirements. Hence there is no chance of people getting jealous of others b/c they're being paid for the same work they're doing for free.. everyone has equal chance to develop the code, submit it and get paid for it. (I don't know if this is what the Drupal users Dries interviewed had in mind when they said they wanted "a marketplace for drupal services" - see attached. Perhaps they meant a more structured way to hire Drupal developers to serve their specific needs, FF is more about a market place for collective needs).

Now about the users steering projects off course: module maintainers will continue to exercise their discretion in deciding whether to accept patches/feature additions etc made on FOSS Factory the same way they do with respect to code submitted from any other volunteer. The fact that one feature was paid for and the other wasn't will have no bearing on the maintainer's decision: the quality of the feature should speak for itself.

I hope that addresses your concerns Daniel.


Accelerating the advancement of Open Source Software

Just do it

Boris Mann's picture

The limiting factor is not money.

I've been successful with the few reverse bounties I've done. I haven't seen end users able to properly value new features or bugs. $50 is perhaps the average for a complex feature, maybe $250 for a whole new module. Not realistic ... except perhaps in developing countries, and I really wouldn't want to see a multi tier system of value created.

The marketplace was, I believe, for hiring themers, fix my bug type of services. That could, of course, extend to code creation, but I have not seen such code make its way into actual modules in the past.

Anyway ... I want to say: just do it. Go for it. Various bounty systems have been tried in the past. I actually encourage developers to have a donate / contribute link right in the project description and on their website. As Kieran points out, there are varying types of developers and motivations.

You might trial FOSS Factory by contacting module maintainers to set up the system and link to it from their project page. Go for it and let us know how it works: you don't need permission from anyone, just have to convince some developers. I don't think this is a good candidate for integration until / if benefits are actually proven, and there is nothing stopping you from giving it a try.

.. and we shall!

abbood-gdo's picture

Great feedback you guys! There are several points I want to address:

Kieran I couldn't agree with you more on the fact that Drupal is based on a new social production model that is very much different from the classical contractual model. However I don't believe FOSS Factory simply follows the old economic model, I believe it's a mixture of both.

FOSS Factory does indeed use the extra incentive of money to compel developers to develop, but that is done while still acknowledging their other motivations which includes solving interesting problems that utilizes their talent and augments their social status within a community.

And here let me point out to Boris as well that it is not necessarily the end users who will dictate what projects will be worked on at FOSS Factory and how much each project is necessarily worth: the end user could be you! You (and by that I mean any seasoned Drupal developer who knows what projects they would like to work on and which has a lot of value add for the community) could propose that feature that you always wanted to add to Drupal but always had to delay it b/c you had to serve you clients needs, to put food on the table. Well now you can create that feature and still put food on the table, or maybe even simply propose that feature and help a little on its design and see far other people's contributions can take it. Because again even if you could potentially be booked solid serving hungry clients for the next 10 years I think we've established that money isn't the only motive for Drupallers to code.

Regarding the value chain argument let me say this: There are more than one way of determining value in the community. True for end users who's business relies on a website the value offered by a drupaller or a drupal consulting firm building their site is absolute. But there are other people out there in the community who would value tools that don't necessarily generate revenue but instead serve a social cause or make something easier to do etc. For example in our experience with FOSS Factory the Open Voting Consortium ( have used our system to produce an open source program to run ballot machines (to make voting cheaper, more transparent and more secure etc), the value add from a business generating point of view is nil but from a philanthropic point of view it is priceless. Further, I think the Google summer of code example is a good proof that not all drupal talent is consumed for website production only.

Finally, the pose no competitive threat to us as they serve a different market altogether: hiring a drupaller to develop for a single client's need, we serve the collective need market.

Anyways, I think Boris is absolutely right that we must prove the merit of this model not by talking about it but by actually producing something of value through it. That's our next step. I'll start looking for a project that could be developed through FOSS Factory that could serve as a case study. Meanwhile if you guys have any suggestions please let me know!

Thanks a lot for the feedback you guys I couldn't ask for more!

Accelerating the advancement of Open Source Software

about organizing funding for events

abbood-gdo's picture

Hey Rob,

Well FOSS Factory is at the moment exactly what it is called: A Factory of free/open source software. However, in principle, there are no restrictions to any project you may want to create on FOSS Factory (ie you could go ahead and create a project called: DrupalCamp Cologne. The description would be just running the camp, and you are the project lead.. subprojects could be getting hold of speakers, creating a site, booking a venue.. etc.. and the community would fund the project)..

actually get to think of it.. it sounds like a pretty neat idea. The only reason why I would probably do that sometime later is b/c of a simple marketing principle I have (and I may be wrong about it): don't let your product be everything for everone. What I had in mind is focus FOSS Factory on the software side, once the model has proven itself then we can make it expand into other fields.

But you know what.. if you want u can go ahead and create that project.. who knows maybe if you rally the community and channell enough traffic to that page on FF, then who knows maybe you will get enough funds and volunteers. It won't hurt the worst case scenario is that you have a dead project, and that's it.

Accelerating the advancement of Open Source Software

Opening up, not only FOSSfactory

Bèr Kessels's picture

There are many external systems that are more or less valuable to certain modules and projects.

A large project like Ubercart could do with a fossfactory-alike system.
A student-maintainer might be helped with a "send me a book from my amazon wishlist of you like my work" kind of funding.
A development-company might want to get all features, bugs and wishes into their own track (or unfuddle or whatever). A thirdparty integrator might want to track the issues in their own queues.

My idea, when talking to Abdullah in Szeged, was that we open up our project module a littlebit.

The end result would be a series of links:
* request a new feature
* post a bug
* donate
(a few more)
* read documentation
* look at screenshots

By default (that is, the maintainer did not change the default Drupal settings) they will lead to the Drupal issue-system, the Drupal donate page and so forth.
But a maintainer could also change the link to "request a feature" into a link to their FOSSfactory entry, or their unfuddle account, their sourceforge tracker, FEvote account and so on and so on.

We already feature this for "documentation", "examples", "homepage" and "screenshots", we could extend this to any tracker/bounty page.


Boris Mann's picture

...individual developers put those links directly into their project node description text. No change required, end functionality still enabled.

My vote is for "just do it" -- Ber, you could easily put a chipin / paypal / whatever link on every project you maintain.

Think we can use this

gusaus's picture

It seems like this might solve a lot of issues we've been having when attempting to build the next gen Dojo site (we'll also be contributing back an install profile, documentation, learning materials, etc.). The issue really comes down to 'who collects and distributes funds' in something in which there is no biz entity, nor formal leadership structure.

To resolve this we are clarifying our goals, crafting support packages, and even forming something that resembles an org/leadership structure. The hangup remains when trying to figure out how to collect and distribute funds.

This almost seems like a great solution as funds could come directly to the producer (via paypal) and THEY could then allocate the appropriate funds into FossFactory for development. Assuming if that's a way it could work, I'm unsure about any tax implications to that process.

I know there is a better way to phrase that, but hopefully that makes a little sense.

Gus Austin

Gus Austin