Project/App Store and Fundraising on drupal.org

Recently there have been a lot of discussion about a Drupal App Store. The discussion was spawned by Rober Douglass tweet:

Your Drupal homework: write a thoughtful blog post on why this would or wouldn't be good for Drupal: http://is.gd/198sUM #drupalappstore

Robert then followed up with a presentation at the Drupal Developer Days Brussels. In it, he gives many good points in regards to the economical nature for Drupal developers, in combination with the open source module Drupal is released under, and how an App Store could make a difference.

Then today Morten Heide tweeted:

thowing the first 300€ into the pool to get imce & filefields to make hot love in drupal7 anyone up for the task? http://bit.ly/dJHxGq

Lately I have seen many comments in the issue queues from users offering to donate to get modules ported to Drupal 7. Another form that is quite common to use on d.o is the ChipIn service, such as for the WYSIWYG project.

These and Dries The commercialization of a volunteer-driven Open Source project post is something I have been thinking about quite a bit, trying to come up with ways of improving this to the benefit of everyone in the community.

Current Situation and Bottlenecks

Users are clearly happy and willing to pay to get modules ready or improved, especially for Drupal 7. The problem is that unless the ChipIn widget is on the project pages, these offers are hidden way in the issue queues.

There are a lot of very talented Drupal users out there that contributes fantastic code to core, contributed modules and themes or help maintaining and improving the d.o infrastructure. While some are able to acquire external sponsoring or set aside time at work for it, its not enough. A lot of important modules are not yet ready for Drupal 7, many modules have bugs and other problems. In many cases it is going to take a long time before they are usable.

This is nothing new when it comes to open source since work is being done on volunteering basis. The problem is that this is also the major bottleneck that prevents the adoption of Drupal. It is that because no one knows when a needed module will be ready or bugs fixed in it, unless they are prepared to someone to fix it.

Companies interesting in using Drupal will usually have no problems paying for getting things fixed. The problem here is that they need to dive into d.o, navigate around to find who to contact about this. Often it is not so clear who to contact about getting things done. If they are new to Drupal this might also lead to that they simply give up in the end.

I completely agree with Roberts view that contributors should be able to earn good money on the fantastic work they are doing. If they where able to do so, I am sure a lot of the above problems would be a thing of the past. Not only that, but we would see many new modules, features and other improvements being released as welll.

Another thing Robert brings up is that besides services, such as support or building sites, it is very hard for commercial companies to get paid for writing code that is not specifically written for a client. Sometimes the client sees the benefit of contributing this code back to the community, other times not. But its not just as simple as uploading a new module written for a client. Often that module is tailored to that clients specific needs. To be generally useful a lot more work is needed. However that time they are seldom going to get paid for and little more happens to it after the upload.

Another bottleneck is that documentation, especially user documentation on d.o are quite unstructured, not up-to-date or lacking completely. Documentation in open source projects is usually having a low priority in the community, so its nothing unique to Drupal. This could also be improved with being able to compensate good writers for the time and work they put into learning and producing the documentation. Good documentation leads to less support needs and makes it easier for new users to get started. It should have a higher priority in the community.

Is an App Store the solution?

Robert talks about an App Store where users pay for downloading modules. He points to WPPlugins as an example of how it can be done. While I agree in principal that something like that would be great, I also believe it easily could have a negative result and raise a lot of concerns.

Even though paying for downloading GPL code isn't against the license, it could easily backfire when users/companies that paid for them discover they could just have gone to d.o and download them for free. In worst case it could even get a reputation as a scam. It would also lead to the same module being available in more than one place, adding more work to make sure things are updated.

Another thing is that it would only be a solution for modules and themes. It would not solve all the other things in the community that could benefit from funding, such as:

• Core development.
• The d.o infrastructure, maintenance and administration.
• Needed improvements to d.o or new feature development.
• Improved documentation on d.o.

We need to come up with something else to solve that. The challenge is to:

• Find a way that plays well with GPL.
• Allow community members to make a living coding for Drupal.
• Add resources to d.o for improving infrastructure, sites, events etc...

Here is what I have come up with:

Integrated Fundraising and Project/App Store on d.o

A better solution would be to implement a fundraising and store solution on d.o to make it easy for anyone to offer to sponsor projects, donate and so on. We could also take inspiration from sites such as Kickstarter where users can present projects and the amount of funding they need to complete them.

Integrating the Contributed Module Ideas group into this would make a lot of sense. Anyone can propose a module idea, developers can then "bid" for doing the implementation and so on. Maybe even rename it to "Project Ideas/Proposals" and include more than modules, such as documentation, improvements to d.o, etc...

Revamping the Project Pages

The project pages are much better after the d.o redesign, but they can still be improved. Especially for non developers they can be quite confusion to read. They also needs more uniformity as now it is up to each maintainer to present their project information as they like.

What I would like to see is a tabbed solution where there are tabs for:

• Overview - Presentation of the project, features, demo site, sites using it, user rating and reviews as well as major sponsors of the project.
• Install & Download - Requirements, including versions and dependencies, installation guide and download options.
• Roadmap* - Information about status and future plans.
• Support - Documentation links including embedding of videos, and issue tracking.
• Maintainers - Info about the maintainer(s) and contact options.
• Sponsoring* - Will list the various options for sponsoring this project, both overall and individual sub projects such as porting to Drupal 7 or implementing a new feature. It would also show completed projects as well as testimonials from those who sponsored them.
• Paid for Services* - Will include additional paid for services available for the project, such as support or customization.

* = Optional tabs

It should also be easy to filter on what major version of Drupal the information should be presented for. Thus when clicking on each tab, only that information is available instead of the mishmash it is today. Each page and tab should also have templates and proper forms so that we get a uniformity for each project.

The sidebar on the overview tab will be used similar to how it is used today, with the exception that the issue block would only be used for number of open issues and list critical issues or problems that prevents the current version from working properly, conflicts with other modules. Sidebars on other tabs will be tailored to that tabs needs.

Something like this would make the project pages much more usable for non developers as it would present information in a structured way and hide away technical stuff in tabs.

Paid for Services

Developing quality features require skilled developers and takes a lot of time. Commercial companies will only do this if they know they have a good chance of making a nice profit from it. The GPL license Drupal core, modules and the code part of themes are licensed creates restrictions for commercial companies when developing for Drupal. Today their revenue mostly comes from added services such as implementation, customization and support. Selling propriarity modules is nearly impossible as it would break GPL. As Robert mention in his presentation, this often leads to that they are repeating the same processes, including code writing, for every new project they take on.

Easier ways for end users to pay for development, such as those I propose here, would make it easier to fund the development, but it is not enough.

A "Paid for Services" tab to each project would add new possibilities. On that tab, the project maintainer, or company, will be able to present themselves and the additional services they offer, including links to their own website for further information. This would open up new opportunities to promote what they do and greatly improve their options for making money on it. I'm sure this would make it easier for commercial interest to take the decisions to develope for Drupal as well.

It would also send a clear message to those interested in using the project since they then will know that they will have access to professional services for it.

The Store

The store would simply be Download & Extend and should be easy to navigate through. It would work pretty much as today but also allow users to add projects to a various bookmark lists, such as download, using, watch etc. Thanks to the revamped project pages the presentation of projects would look much better.

Adding features to group projects together would be nice. Then for an article about creating a blogging site, all needed modules, themes etc can be added to the download list with one click. Any user should should be able to create these lists, inclduing adding them to project pages, document attachments and so on.

Each project listed will have a short description based on the current official release, not just a trim from the project page. It should also be possible to add info about fund seeking. A D6 module could then add "Seeking sponsoring for Drupal 7 port". Thus the module will be listed when filtering on Drupal 7, but highlighted that it is not ready.

Each user on d.o will also get an overview page, added to their user account, where they can see what projects they have helped funding, who has contributed money to their projects and so on.

Funding/Sponsoring Page

Other projects that needs funding/sponsoring such as projects for major infrastructure changes, including improving or adding features to d.o, Drupal events, etc., would be placed on this page. They would have a project plan and goal list.

This page would also contain a list of Drupal Core projects that can be sponsored/funded so that development can be speeded up.

These projects should also be possible to add to the homepage as well as the sidebar on many pages.

Administrated by Drupal Association

This should all be administrated by the Drupal Association. In return they would get a cut from each project being funded. The "Paid for Services" tab will use a subscription fee that goes directly to the Drupal Association. Project owners with many projects would be able to get discounts based on number of projects they want the tab available for.

This cut, together with the fees for the Paid for Services, will be used to cover the costs of running the store as well as help funding projects on d.o in general as well as other activities in the Drupal community, such as DrupalCon.

However, just creating the store and let it lose is not enough. There are many more issues that needs to be addressed before it can be done, such as:

• Requirements for who can create a store account.
• How complaints are dealt with.
• Who is responsible if a developer/company does not fulfill what they have been paid for.

There are many other issues that needs to be addressed before a store on d.o can be rolled out. But in my view, the possibilities easily outweighs any of the concerns and problems with it.

Conclusion

If this is done right it could lead to a great boost for the community. It would help funding improvements, as well as open up for possibilities to have full time staff that focuses on many important tasks.

I am also convinced that implementing something like this on would make Drupal much more interesting for commercial interests to invest in, especially when it comes to developing modules. When they look at the financial investment they have to do for developing, they will know that new promoting options on d.o will offer them a much better chance of recovering that investment and make a profit.

In the end, everyone will benefit from this:

• The Drupal Community will get new exiting modules, themes to use since it will be easier to get paid for the work.
• It will be easier to seek funding for existing and new projects, not just core and contribs, leading to quicker releases
• New resources will be available for improving d.o and make it even better.
• It will help attracting new users.
• Make it easier for Drupal to be selected for new site project of any size and budget.

Most importantly is that it would make it much easier to keep the momentum going!