Is it Evil to Ask For Payment?

$First, remember that we're all friends and we all share the same goal. What I'm going to ask is how to best get there. If you think I'm flat-out wrong, please say so.

Drupal core is extremely powerful, but without all those contributed modules, it wouldn't be as successful as it is today.

Our problem is "how to make module development sustainable?"

Most contributed modules were created because someone needed something that wasn't there. Then, they added the module to Drupal's repository, so that others can use it and improve it.

However, the heavy lifting remains the responsibility of the author. While community members help enormously with bug reports, patches and ideas, most of the work remains with the author. As modules mature and become more popular, ongoing support and maintenance becomes a significant task.

And now that Drupal 7 is out, this work basically doubles, as D6 and D7 are very different beasts.

My Theory - Paying for Modules will Drastically Improve Them

For the last year, we've been working on the Translation Management module. It's a complex project that powers some of the larger multilingual Drupal sites around. The folks using it save thousands of dollars every month on management of translation work.

Our little dilemma is how much time we allocate to handling user issues and how much time we dedicate to building our own translation system.

Right now, all of our Drupal translation clients are running smooth without any technical or workflow problems. It's taken months to get there. However, there are quite a few others who are using our module without our translation service.

We do our best to support everyone and make our TM module play nice with every possible Drupal configuration and with other major modules. The problem is time. When we debug complex problems for others, we practically neglect our paying clients - the ones who make all this work possible for us.

Asking money per support issues is a bit like running a beg-ware business. You find yourself in endless negotiations whether someone found a bug and you should be paying them or whether they should be paying you for support. It doesn't work.

If we could charge a small fee from everyone using out module, we would be able to spend far more time into making it more robust, perform faster and more compatible with other modules.

GPL Means Free as in Freedom, but not Free as in Beer

Just because modules come with a GPL license it doesn't mean payment is a bad idea. You can think about it anyway you like and give it any name. The end result is the same - you're sponsoring the tools that you use for your business and help them get better.

When you pay for something, you also get something in return. The promise of a for-pay module is support. If you could pay for a module, you would deserve reliable support.

This means that when you run into a problem or you need help, there's an address and there's commitment. When you create an issue, you know that there's a maximal time until it's handled and that time is measured in hours, not in weeks.

What do you think? Would you be willing to pay for using modules that you depend on?


It's a tricky debate - we've

It's a tricky debate - we've looked into Joomla before settling on Drupal and more recently we've checked out Magento, so far , the need to pay for modules on those platforms has made me realise how great the Drupal philosophy is. That said, we can see what happens when there is investment, some of the great work coming out of Acquia seems to be pushing things forward.

asking for payment is right

asking for payment is right dude

Is this module dead? I'm new

Is this module dead? I'm new to Drupal and think this 'Translation Management' looks great. However the last blog post is from January, so it looks abandoned.

Looking at the comments I can see that there are an endless number of ways to justify not paying for something. But at the end of the day, if you need money to continue development, why not just ask for it? I can't see anywhere on this website where I could make a payment.

Not dead, but not being developed forward

Translation Management is not dead. We're doing maintenance updates for Drupal 6. These updates are mostly required for our translation clients.

So, as you can see, where there's money involved, there's action.

If someone can explain to me why we should spend months of work on something that has zero return, I'd love to understand it.

I think there is a small

I think there is a small solution for all this, drupal should give you a flag for the user that make a donation or support to your module and send them into the top of the bugs or issues list, so they get more help and support from you.
and this will push someone else to donate to get more support from you ;)

No suprise that Drupaller is against $$$

Sometimes I keep wondering why on almost every drupaller comment I read on the net is against making money on selling modules but it is OK to sell themes?

If themer can get away / circumvent GPL by licensing their css/images/js in different license than GPL why can't module developer create a separate php class api that doesn't touch any of drupal api and license it with commercial license?

You can release a "lite" version of the module to and sell the "premium" version at your site, maybe the "lite" version is tailored for small to medium site and the "premium" version is tailored for large corporation.

That method is also used by RedHat / Fedora, while RedHat is expensive (stable) and Fedora is Free (their playground for testing new software) and also Drupal / Acquia, Drupal is the playground for accumulating new module for Free while acquia is the money making machine.

Or you can start a membership site where all support is for paid member only, so you can leave the free member hanging for weeks in issue queue (dont worry that is a standard practice for many modules these days)

Anyway that is only my 2 cents. dont shoot me with zealots.

Drupal spirit

Drupal is not just an engine, it is revolution. Drupal is so flex and powerful that allow to make all kinds of sites. You want e-commerce? No, problem. You want social network? No, problem. You want social network + e-commerce + blogging and collibrative tool? no problem. Drupal is revolution that move Internet forward. Google likes Drupal because of this. Drupal allow to make good quality and SEO frendly sites. Do not forget that site and code is not the value of business it is just a tool. Tool that have probably the best power/cost relation. And that moved Drupal to the top. So in some case that gives you and you businesses competitive advantage. That is very good that some companies made feedback to the community with code, donations and patches. I suggest to think not about how to ear on selling code, but how to make Drupal grow. We can:
1) Add donation button on module page
2) Make a fund for drupal grow. That fund can collect money with several sources. First one is grands and donations from companies like Google, Microsoft and etc. The second way is to send target messages to site owners. Drupal have tool to collect how many sites used current module. We can just to that sites message like: "Thank you for using Drupal for you site, we'd like to make your project better by doing better Drupal. But we need feedback from you. You are using Drupal and 20 modules how much money do you think it save you? How much do you think you can feedback to drupal? Please do this -> Donate (Recomendated 50$)".
Guy who saves 4000$ by using Drupal will pay 50$ I think. But we will have the problem of hadnling that fund to have most profit.

same applies to Wordpress

As I was calling out Matt Mullenweg, I've seen Everett Zufelt pointing to this blog post about previous discussions of the topic regarding Wordpress: Quoting from there:

"I mean honestly, plugin authors are left with very few options when it comes to developing plugins for free under the GPL full-time while also making a decent salary. Matt Mullenweg continues to harp on the fact that the code is not where the value is, it’s what is built around that code. For instance, support forums, custom development, lead-ins to consulting work, plugins which serve as a resume to work at a company full time as a programmer, etc. The same could be said for premium theme authors but as we already know, they seem to be doing just fine throwing the GPL to the wind and doing things their way with no repercussions."

"I love WordPress plugins and I don’t want to see so much talent jump from the WordPress ship because they can’t make a full time salary developing and then supporting these plugins. Some would argue that the very nature of the GPL license prevents those from making this living by not being able to appropriately license their code. Well, if that is the case, then it’s time you go to a platform that has a license you agree with or can make a living with because WordPress is not moving from the GPL anytime soon if at all."

That was in 2009. We're now in 2011

Things have changed in WordPress, and only for the good.

Anyone I've talked with, who sells WordPress plugins, is extremely happy. They stopped doing any sort of contracting work and are hiring more talent for new development and support.

I'll be happy to report our own results here, in a few weeks, as we're turning our own WordPress multilingual plugin into a paid product.

I need to explain the non-issue with GPL.

The GPL license means that anyone can do whatever they like with the code.

However, if someone grabs my code and puts it on their own website, it gets zero credibility and doesn't pose any threat to the business.

If it goes on D.O, it's immediately accepted as the default distribution channel and kills the business.

Until we get a firm commitment from the folks running, that they WILL NOT ACCEPT ripped code, there's no chance that this will happen.

Since the opposite appears to be the case, we will be removing functionality from our module and turning it into a gateway for a hosted translation management solution. Instead of paying a one-off fee for the code, end-users will pay a monthly subscription, which is just fine with us.

Wow I'm gonna do something

Wow I'm gonna do something bad and comment without reading the two pages of comments.

A few thoughts:

- You should ask the Joomla community how well that model is working for them - not very well.

- I think you might be missing some of what working on a module for free gets you - advertising. ICL is known as the go-to translation service for Drupal. That's because you've built a solid module.

- Remember that the Internet doesn't work like traditional commerce, free must be part of the plan in some way in order for your idea to survive. The freemium model works in several places and while your current model is kinda like freemium you might consider going all the way with it.

- You don't have to implement everything/anything that people ask for. With my modules I really only fix bugs for free. If you want a new feature you're welcome to hire my company (or anyone else) to build it for you. I'll only accept contributions from others if they are well written and will not cause an excessive maintenance headache for me down the line.

I don't think there's a

I don't think there's a universal solution that fits every case (product, service, developer).
I do think that making money via consulting is the best option, and I've made much more money customizing my first few Drupal modules than I would have ever gotten selling them.

I read somewhere (37signals blog maybe?) that you can only count on 10% of your user base to pay, so that should be kept in mind when looking at usage statistics.

If you can't see another option, go with what you've envisioned. Be bold. Charge for downloads. Be the first to try it, success or failure. If it turns out okay, and funds the development as expected, you can always return to providing it for free and then customizing it.

However, I'm afraid that you won't see the money you are expecting to see because drupal people are not used to paying for downloads, they are used to paying for services, AND you can't stop them from freely redistributing it after they've bought it. So you might have 10 "free" copies for every 1 sold copy.

It's your risk to make, and I wish you good luck in any case.

Thanks. I think that your

Thanks. I think that your analysis is correct. I'm not sure what we're going to do, but I'm not going to ignore all the great advice I got here in all these comments. That's why I wrote this post before doing anything.

Make better use of the community

If someone needs Translation management for D7, let them help post porting patches, or help co-maintain the module with you. If you can't afford to work on porting and maintaining a D7 version, then what's forcing you to have to do it? Wait until a client that's on D7 needs help or the community helps you do it. Don't build yourself into a walled garden, cutting yourself off from help or development from the community.


Please correct me if I'm wrong, but my understanding of the GPL is that only one copy needs to be sold of a GPL product for it to be redistributable free of charge from then on. So one could buy your module, and redistribute in on or elsewhere free of charge for others in my understanding. How do the mentioned Joomla and Wordpress shops come over this?

GPL v2 that is used by Drupal ( comes with this note on charging money:

You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

So you are entirely all right to charge for the transferring of the copy (eg. the bandwidth used), or if you choose to provide warranty. However, once that distribution takes place, those who buy it from you for the price of transferring the copy, can then redistribute it since section 1 applies to them:

You may copy and distribute verbatim copies of the Program's source code as you receive it

and section 2:

You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

My understanding is that the goal of the GPL is to give you all freedoms with the source code when you obtain it, and for any derivative works (such as Drupal modules are to Drupal) to retain these freedoms.

If you can / would make your module to not be a derivative work of Drupal (eg. work alongside it as a standalone application or include a binary with your module that is required for the functioning of the module but is not using Drupal in any way, such as a standalone daemon to do jobs on behalf of your module), you could free yourself of the need to provide these freedoms so to speak. Then you can choose to license your non-Drupal component any way you wish and be independent of the GPL. People could still distribute your module under GPL but not the other component which would be required for the module to actually be useful, thus defeating the purpose. However, you advocate working within GPL, and this would merely circumvent the GPL via the well known "services loophole" as we know it (

However, I do not see how the GPL would limit the redistribution or allow you to limit the redistribution once you "sold" even only one copy. What points in the GPL do mandate that your clients apply the same fee for transferring copies as you do? Or apply the same fee for redistribution if they do not provide the same warranty that you do?

GPL means your clients can resell or give it away for free

Since the code is licensed under GPL, you're not really selling the code itself but whatever services you provide from your site. This may include the download and any support that you provide.

When someone gets your code (purchased or otherwise), they can do whatever they like with it. This includes selling it, giving it away, putting up on D.O or whatever else, as long as the GPL license is kept. That's fine.

WordPress that sell GPL products have no issue with that. Almost all clients are web developers who use this work to deliver working websites for their clients. Besides access to the code, they need ongoing support and access to documentation.

They also understand that when you use a plugin (Drupal module) it has to be kept up-to-date. Just ripping out one version and remaining stuck with it is worthless. Without someone who's responsible for the code, there's not much to do with it.

If I develop and sell something for Drupal and it goes on D.O for free, and D.O webmasters allow it, it's going to cause me to discontinue this work and seek other venues where this sort of thing doesn't happen.

Even though Automattic doesn't particularly like paid plugins, they would never allow this kind of misbehavior on the WordPress plugins repository. It's legal but it's wrong and it hurts everyone's business.

legal but wrong?

Well, in my view, the primary goal of the GPL is to retain the freedom of tinkering to avoid dead-ends and to avoid someone building on your free software to take advantage of you. Imagine you write a "green_grass" module and publish on Someone takes your module and writes a "greener_grass" module and sells it on their website for a nice sum of money. Well, the GPL is supposed to protect you from this to happen, if the new module is derivative of your work. They'd need to distribute greener_grass free of charge and should only ask for money up to the cost incurred for transferring the source (which given how small Drupal modules mostly are, is probably a couple cents).

Now what counts as derivative work? In my example, green_grass serves as base for greener_grass. But do both serve as derivative works of Drupal and therefore fall under the same requirement? As far as I understand, they do. The same thinking applies to not just Wordpress plugins but themes even, for the source code at least that interferes with Wordpress, and the recent Thesis theme hoopla proves that:

The application of this to Drupal themes is clear. If you look closely, you'll see that most if not all Drupal theme marketplaces build a base theme and publish on free of charge. This makes people use their base themes, get bug reports and fixes, etc, but that code is GPL bound anyway, so why not publish? They do sell Drupal themes though, due to themes having components which are not derivative to Drupal, not source code running in Drupal's environment. Namely images and styles. The rest, the base theme is on to tinker with.

Not many Drupal modules exist, which do not work with Drupal via the theme, node, menu, etc. systems, and if there would be such modules, they'd be so independent of how people used to work with Drupal (eg. customization via standard themes, editing on the node UI, building views based on the data, etc.), that the community would find little value in them. So finding ways to free modules off of the rules of the GPL sounds pretty far fetched.

Yes, there are for profit components, base themes, etc. for Wordpress and Joomla. I think Matt Mullenweg sent a pretty clear message with the Thesis case on Automattic's stand. As far as I see, the Drupal community was always true to that thinking. Yes, the GPL is written to protect developer and software freedoms and has few considerations for business, or when it does it protects the developer and software freedoms vs. business.

Thesis 1.8 is GPL. If someone

Thesis 1.8 is GPL. If someone grabbed a version of Thesis and submit it to the free themes repository on WordPress, it would not be accepted.

I'm pretty sure that doing so with themes from TopNotchThemes would not pass as well. It's legal but it wouldn't pass.

What makes modules different?

You're missing that there are

You're missing that there are components of themes that aren't "tainted" by the GPL and are therefore subject to additional restrictions that would make them ineligible for hosting on d.o. Rip those components out and the GPL code can sit there if it's turned into a useful project, meaning it would require new CSS and images... i.e. a new theme.

Modules are different because they are. There's plenty of information about this around the community blogs / d.o.

But for the sake of argument, let's say someone did decide to defend your for-profit cause and prevent a copy of your GPL code from appearing on d.o (I don't think this would necessarily happen)... I can just post it on GitHub and make sure people know how to find it if they want it.

Nothing about the GPL or the community gives one person the exclusive right to distribute his or her modules. Further, if someone is willing to maintain the "free version," it would be in the community's best interest for that to happen on d.o where a maintained free version is available with all of the community trappings and visibility.

I've got to disagree with you

I've got to disagree with you when you say 'it's legal but it's wrong'. If someone wants to fork your module that is distributed under the GPL, they have every right to. I'd guess an example of this is CentOS being a fork of Redhat.

That's the agreement you make when you use someone else's code in your own module, you have to respect the wishes of the people who created that code in the first place.

It's fine for you, but I would still not be involved

The Drupal modules repository is not governed by GPL only. GPL is a license, not a policy.

D.O. webmasters can accept or decline modules based on different criteria.

By chance, it happens to be that our work is almost all original code (Thickframe is probably the only exception). If someone decides to take every new version that we release and simply mirror it on D.O, it's within the GPL license but an unreasonable thing to do business-wise.

Since I'm pretty sure that this is what will happen, we're not going to try that and will spend our energy on places where we know, for fact, that this behavior is not acceptable.

We are going to keep maintaining the Translation Management module on D.O, but not on the capacity that we intended to do. webmasters do not get webmasters do not get involved with forking. Generally we try to apply community pressure to get people to merge projects, but there's nothing we can really do. And I'm not sure how much community pressure would happen the other way around if someone forked a pay-for GPL module and released it on

I'm not sure that your module

I'm not sure that your module is almost all original code. Whenever you use a Drupal API function, you are including the code that that function calls.

So for example, each time you call node_load you are including code that somebody else has written, and when node_load runs it calls other Drupal API functions itself. If you go through and add it all up I wouldn't be surprised if 'your' module was actually mostly comprised of code that other people had written.

And that's actually the strength of Drupal and other open source ecosystem. Instead of writing everything from scratch we're using code that has been built and tested on hundreds of thousands (millions?) of systems. The trick is to finding a business model that works within that framework.

Forget downloads, do professional services.

Forget payments for downloads, but do provide professional services and support.

It is your responsibility to find the right balance between "simple" or general purpose bugs, features, and support requests — and those requests that are more complex, custom-tailored, good but challenging ideas, and whatnot.

Make sure to elevate at least one other contributor and grant him/her d.o project access, and require a peer-review and approval by this user for all commercial changes you want to do. Do this to ensure sanity in the project's evolution — whatever you do commercially also needs to make sense for everyone else.

Keep your project's queue clean, but don't treat non-paying users as chickens. The time you start to do that, your plan will fail.

In the end, bear in mind that the most significant changes are way beyond of paying users and customers. You can scratch your own itch, but the product or service you build is doomed to fail if you don't invest in, talk, and listen closely to the community.

In short:

Your idea/plan is not problematic. Your challenge is to properly identify the environment factors and risks, in order to execute the plan successfully.

You're right, it's not going to fly in Drupal

From what I gathered here, it looks like trying to sell modules for Drupal would mean swimming upstream and we're not going to do it.

It's a shame because it means that we're going down from two developers on full time to one developer 4 hours per week, but that's how it's going to be.

I know that you're a major contributor to Drupal and you have your own business model around getting premium contract work via your Drupal contributions, but you must realize that what works for you may not work for others.

Paying for a module does not

Paying for a module does not guarantee support. Paying for support guarantees support. Don't try to pass off paying for modules as good for the modules' users.

Totally agree with catch & co.

I won't repeat what all people said. The model described is precisely what makes Drupal this good.

So my advice for the TM module (which is just awesome for multilingualism) : use the power of the community ! Don't just ask for help, even if I can understand your need for help. But organize it : physical or virtual meetups so you can grow your user base, sprints so the development can advance, dojo session so you can train people to help you. You can even imagine, as it's done for other modules, organizing paid training sessions. In true open source, code is free, but transmission of knowledge can be monetized : we have free and paid documentation (d.o and blogs vs paid videos or training sessions or books). In the end of the day, to make it simple, you'll have your issue queue more active, and may even find co-maintainers to "do the job for you".

we should pay for features, not use

For-pay support is definitely a model with promise and worth trying. Try to avoid keeping key pieces online and proprietary though; that i think is bad for the ecosystem.

At best, though, it's a roundabout way to subsidize development costs. The way for free software to blow proprietary software out of the water in quality – because we have a superior development model - is to to get a better funding model, and that means people organizing to pay for software in advance.

Jan's ideas, and a tip jar for sponsored modules that original donors and developers could decide how to distribute toward new work would be a great addition to that.

We have a lot of plans in this area for 2011 (and have a not-for-profit organization that could support it; the Drupal Association has made it clear they are not interested in leading something like this). If you're interested also contact us.

It's a very difficult model

We tried it, for almost a year, and it's a very difficult model.

When you charge for support, and there's also a free support channel, you get only the most desperate support issues for pay. These cases are so difficult to handle that it's not economical.

I wished there was a donate

I wished there was a donate button on module pages, or a 'sponsor this feature' donate link on feature requests. Lately I've been jumping on board donating to my favorite web sites like Wikipedia, developers and bloggers, it's more rewarding. Have even set up recurring monthly donation on my favorite blogger.

Another, sorta unrelated, feature is approving more themers as co-maintainers on modules answering theming questions. There seem to be a fair number of people in the issue queues asking theme related questions. Could be looked at as helping people visualize how to use the module, like staging a new house with furniture to show to buyers.

Just to suggest something

Just to suggest something different, regardless if unrealistic, what if a common pool of donated money paid people to support the contrib module developers.

Curious from a development perspective does 7 make things easier for developers to maintain/support their modules?

For the record, I support a Drupal "app store" model.

I think it would live separate from, be a private for-profit venture, and would function as a central dispatcher for modules that need to be paid for to download. In its simplest form it would be just that - pay for the right to download - and nothing more. Perhaps a more nuanced and developed version would allow for support subscriptions as well, but when I think of the Android app store, "support" isn't really the first thing that comes to my mind.

The problem that needs to be solved here is that there is absolutely no market in Drupal for independent software vendors (ISV) of any kind. It is nearly 100% services driven. All the money involved is earned by people who take the Drupal platform and add value to it by consulting, custom-developing, and so forth.

If we *don't* create a market for ISVs, we will remain a much smaller industry than our ultimate potential. Most mature software industries are composed largely of ISVs. We have none.

Drupal isn't an industry in

Drupal isn't an industry in itself though. It exists in a sector that has plenty of 'independent software vendors' - they're called proprietary CMS. Pay-per-download will just bring us down to that level.

The camel nose in the store

My opinion about this kind of store is that all big Drupal modules, sonner or later will move to this App Store. So no more free modules on Drupal.

Do we really wants ISV entering Drupal? The real problem here is not how to become more "mature" (we have a lot of good written modules, the most important ones have a lot of documentation from differents sources, there is a Security Team for free!, something for example Jquery modules lack of, if that is not mature, what can be more mature than this?), the problem here is how do we as a community can payback all the humongous quantity of time drupal developers put on resolving bugs and/or improvements in their modules.

If all the big Drupal modules

If all the big Drupal modules became paid modules, and play perfectly with each other and have excellent support, how would that hurt your web development business?

Well Im sure this is a

Well Im sure this is a special case, but Im from South America, and it is difficult for people here to use a credit card to PAY something in internet.

And its not that it is impossible but for example I have a lot of virtual credit cards to pay for hosting or domains but they are not realiable and i have to change them every 4 or 5 months.

So even if you want me to pay you 10 cents of a dollar, there is a intrinsic barrier here. It not 10 cents, if going physically to the bank to get a new card, or put some credit in it. Then i can pay you your 10 cents.

So I may not be the only one with this payment problem. Also, if I have to pay for Drupal, then automatically Drupal will become in my mind another software for pay, that lead me to compare between other non free software.

If that where the case then it would probably be more easy for me to start learning another CMS that comes with free modules.

I have to say again, that maybe this is not a money problem, this is a problem of delegation of work. How about this, what if you can only download a module with an drupal user. If you download a module more than 2 or 3 times, you own that module 3 hours of works or something like that. Then if you want to download
more of this software you have to find and resolve a patch. It just a crazy idea but its an example of what kind of solution open source software can have.

Would separating this "App

Would separating this "App Store" from D.O. take care of GPL licensing issues? If so, it would probably be healthy (or at least profitable) in many ways, but imagine the effect of this and say smallcore together, what you begin to create place for is a magento or sugarcrm or whatever, where the FOSS side of things become second class to make way for the VC's...and thus the innovators dilema sneaks into the picture in a new way, someone small and bright and free-er get's it's way in the door...hopefully node.js/express :P

That's the horror story ;) , but yeah it could be really flipping great, I've always looked to SaaS as the ticket for drupal "products" but maybe with the momentum already gained or gained by the time something like this came about one need not worry...

GPL is not an issue

Since Drupal runs on GPL, modules should go with GPL license as well.

It's not an issue. Having a GPL license means you're allowing people to do whatever they like with it, but you can still charge money for the right to download it from your site (and obviously, for getting support).

Have you thought about a SaaS model?

I'm currently developing a software service using Drupal, with all the 'critical and valuable' logic in a closed source environment, while the user interface and normal Drupal business logic lives in a series of Drupal modules. I am using the Services module to create a webAPI that tunnels requests to my service into my separate Drupal install living in the cloud that securely holds the closed source logic that provides the service.

Still in the process of building this out, but we plan on a model where the initial use of the module is free, and at some point a user has to become a 'subscribed user' or the service no longer works.

Would something like this be possible with what you're doing?
Getting paid is critical, and providing a critical service is something that one should be paid for. I consider translation services to be an example of a critical service.

SaaS is great, but a different thing

Some types of services are excellent as SaaS offering, but what everyone here is saying is that there's no room for selling product-grade applications for Drupal.

That's pretty bad and pretty much explains why these applications don't exist today.

Everyone may be saying that

Everyone may be saying that there's no room for selling product grade applications for Drupal -- but I firmly disagree.

As Guy Kawasaki says "Don't let the bozo's bring you down"

Use drupal to make the next profitable and en vogue mobile app -- make money, then re-invest part of your earning into the community and everyone will be pleased.

I think drupal can power scalable web applications --
perhaps you guys could build something to be the next Rosetta Stone -- that would be great.

I think drupal would benefit from this more than from selling modules --

I don't think module

I don't think module maintainers should consider the position a business model, from my observation (as not a maintainer) it is a responsibility that one wants to at minimum hold onto long enough to bring others on board with them to maximum hold onto to direct it while it makes sense/aligns with passion.

That said, I'm sure there is plenty of money to be made (I've made some of it) extending modules to someones specific use-case. If it's needed, it will probably be paid for, a measure of sales tactic comes into play here.

If a module isn't generating money but is generating tons of support requests, like someone above said, the pain of that will likely cause action:

A) it will encourage someone to help
B) it will encourage someone to innovate

If maintainers are willing to include another to co-maintain or spend enough time nurturing issues (soliciting for patches, co-maintainers, being cool, whatnot) then things tick over and what isn't a business model can still make money.

My 2 cents...

Maybe this can work

I dont agree to pay for using a module, that would cut the massive eyes necessary to find bugs in a module. Also it will bring you a lot of troubles, because the buyer is paying you for a product that works, in any scenario, like PHP 4.1 and yourSql 99.0 ( hope this joke is understandable) in a Solaris workstation fro circa 1996. Yes that smell like troubles and headache for you, payed headache of course, but don't forget about possible litigations because jerks exist everywhere.

What I agree is that all your effort (believe me you're like some kind of hero for me) should be payed in some different ways.

A) Advertisement, in the page where you download the module, you can be allowed to put an advertisement link, indicating somethink like "If you like this module, then go ahead an get me some money by looking at this advertisment, I need it for my daily inyection of coffelatte". Maybe some percent of that money can go to the core. Is all about how do you say it. Trust me people like to help, when its easy to help.

B) Badges and Medals, people that make a donation get a medal/badged related to your module. Maybe the medals can be different each month, so people can start collecting those, and interchanging them. Lets get social with it, and publish them on facebook or something, people like to collect stuff.

C)I don't know why do you say that Wikipedia models don't work. I mean they collected millions of dollars in some months, so is not bad after all.

I dont really see a problem with big modules getting bigger, and small ones getting smaller. Drupalution dictates that bigger modules assimilated smaller ones. Maybe smaller submodules can win some of the cash that big modules have.

Trying to win money from Open source is not bad, but trying to obtain that money "directly" from the final user is not Open Source anymore.

Different expectations

I maintain 3 modules. None of these were paid for as they were all created originally for my personal website, which doesn't make any money. I have donate links on all of them that get used now and then but that hasn't brought in enough to pay for even a small fraction of the time I've spent on them.

I don't mind giving my time to the community for free in general. After all, I'm taking freely of other peoples' time when I use Drupal & its contrib on my own sites. It's a cycle of giving and taking that's almost a barter system.

I do burn out, though, now and then. While much of what I do on the modules benefits me and my site, there is quite a bit that I do that only benefits the community. And, in fact, it _hurts_ my site because working on the modules takes time away from working on my site. So I get frustrated, especially when people get demanding in the queues.

That said, I don't like the idea of a pay for modules system. When you pay for something, no matter how little, there is a different expectation. You've put money towards it and you expect it to work perfectly and your questions to be answered timely. And I just can't promise that unless the cost is high enough that I could hire a babysitter for my kids and work on this full time. And people aren't going to pay _that_ much. :)

So, for me, the amount of money you could reasonably charge for a module isn't enough incentive for me to match the expectations that would come from selling the module. What I would rather see, as was mentioned above, is a more integrated donation system to make it easy for people who are able and willing to pay to do so with the understanding that they are donating in response to what they have already received rather than paying for an expectation of future service.


And if someone is committed

And if someone is committed to producing a polished product and is willing to support it, what's wrong with just paying for it? Why doesn't it have to be donation?


I think you missed the entire point of my post.


I already get paid for my modules

In my experience, every single module I've published was created to address the need of a company or a client, in which case I got paid for it.

Me supporting my own modules is a way of keeping my customers happy and more work coming my way. The quality of my modules is really my only ad campaign, and it works to keep my skills up to date with regards to Drupal. I provide the support for "free", but really, it is that support that keeps businesses coming back to me with more work, so even though it's "free", it's still quite profitable.

It's iffy

Have you read the recent blog post from the MajicJungle folks about their experience charging for an app in the Mac App store?

To paraphrase: charging for the app made people more entitled and, frankly, rude. If anything he feels beaten down and /less/ likely to work on it more.

Obviously this isn't the case for everything, but it's certainly something to think about. I'm sure you've gotten your fair share of rude/entitled people in the issue queue; you'd have to consider if the amount you may net from selling the module would be worth possibly being treated like that.

Is there anyone else that currently contributes modules that is asking money for them? I couldn't think of any and a search didn't return any that I could see.

I think that this would be a great panel discussion, though. How are funds currently raised for development of the module, if anything? What has to be done to finance the maintenance of it (because you obviously would be either turning down paying work to maintain, or doing it in your free time)?

Up until last month, we had

Up until last month, we had two developers working on this module full time.

To maintain a module of this size, takes a huge investment in time. Now, we're facing a big dilemma with Drupal7.

Getting Translation Management to work on D7, fully, including all its new language features, will take about 6 months of hard work.

We're not going to see a single translation client on D7 during 2011, so return is going to be exactly zero.

Without any way to finance this work, it's not going to happen.

Stress the open nature

I think making it easier to donate, donations more integrated into the site, ect... would be more valuable combined with stressing the idea of open sources and community development/help. This idea is a good one and it doesn't just apply to Drupal. Anytime such an idea can sink into someones skull just a bit... that is a good thing.

I didn't even know I could become a member of the Drupal association until recently. I intend to join after I move.... but I think this just illustrates things need to be stressed more.

Donations are negligible

Anywhere on the web where people do great projects and ask for donations, the amount raised is almost nothing. Take Wikipedia as a great example.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options