In the Open Source software community, there is a considerable nervousness regarding paying people to work on volunteer-driven projects. For example, Joomla recently hired some developers to work on their core software, a decision that has caused much debate in their community. At Drupal, we recently hired a temporary staff to help with the redesign. There is an understandable concern that the spirit of volunteerism will be lost or a volunteer project will be tainted when a paid staff is introduced. There are worries that a project's agenda will change to suit the needs of 'privateers'. However, many projects that rely completely on volunteers fall short of what can be done by a paid staff. Some projects can't afford not to make use of the benefits that a full-time, focused staff can provide.

The concept of major projects growing out of a volunteer, community-based model is not new to the world. Throughout history there are examples of pure volunteer organizations that were instrumental in the founding and formation of many projects. The first trade routes were ancient trackways which citizens later developed on their own into roads suited for wheeled vehicles in order to improve commerce. Transportation was improved for all citizens, driven by the commercial interest of some. Today, we certainly appreciate that our governments maintain the roads. However, we still see road signs stating that a particular section of a highway is kept clean and trim by volunteers -- at least in some countries. When new ground needs to be broken, it's often volunteer communities that do it. But a full-time, paid infrastructure can be necessary for the preservation and protection of what communities begin. And when new advances are to be made or gaps to be filled in, volunteers rise up within the paid infrastructure. There will always be a place for volunteers, just as there is a place for professionals.

It's quite common in the software industry that great movements are started by volunteers. While this can work quite well initially, there comes a time when a volunteer-based project becomes a threat to larger, controlled organizations (e.g., MySQL to Oracle, Linux to Microsoft). At that point, if the Open Source organization is to survive and compete, it may have to fortify its position by fostering commercial involvement that helps the project advance and compete. Red Hat is a good example. Without Red Hat, Linux might not have the strong market share it has today. It is also one of the reasons I co-founded Acquia, and why it is important that all Drupal companies contribute back to the project.

Within the Drupal project, we don't have a paid staff to advance the core software. However, many of the developers who contribute to critical parts of the Drupal code base make their living by building complex Drupal websites. Some Drupal developers are paid by customers to contribute their expertise to the Drupal project or are employed by companies 'sponsoring' Drupal development. Tens of thousands of developers are working with Drupal today, and many of them contribute back to the project. Albeit different, neither Joomla or Drupal are exclusively a volunteer run project, and that is one of the reasons we've grown so big. Ditto for WordPress that gets a lot of help from Automattic.

Volunteers rally together at times when they're needed and they play a critical role, particularly in the beginning. Without them, we would be nowhere in the Open Source software industry. Over time the maintenance and operation and in some cases the leadership are transferred to paid personnel. We have to accept into our projects those with commercial interests, without capitulating to rigid and narrow commercial interests. The commercialization of a volunteer-driven Open Source project is part of a project's natural life-cycle. While it can be a significant change, it is a great opportunity. We can reap the benefits of growth, prevent volunteer burn-out and distribute the effort.


Brian Teeman (not verified):

Accepting into our respective projects those with commercial interests has always been one of the major quid pro quo arrangements that have allowed people to contribute. However that's not the same as the projects directly employing people directly to work on specific areas of management, development or design.

I'd argue that Red Hat isn't a good example as it was founded from day one as a commercial entity (which at least in the early days did no development of its own to contribute upstream).

For every open source project that has successfully integrated paid employees into their structure there are just as many where this has had a negative and counterproductive effect. Anyone remember the Deboan dunc-tank project?

Is the commercialization of a community project something to worry about? You say no but I say yes. Just because you start to pay someone for their work doesn't mean they will work harder, better or more efficiently than the volunteers that did the work before. The assumption that people are motivated to produce their best work by money is a faulty one. More people are motivated by satisfaction, enjoyment and recognition by their peers. That is what has got so many successful open source projects to the position they are in today and it is foolish to ignore that or to conclude that changing the successful formula is not something to worry about.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.

Jeff Eaton (not verified):

"Just because you start to pay someone for their work doesn't mean they will work harder, better or more efficiently than the volunteers that did the work before. The assumption that people are motivated to produce their best work by money is a faulty one."

Absolutely! For large distributed projects, though, there are often certain kinds of infrastructure that depend less on the best and most motivated than they do on the most reliable and most responsible. In Drupal's case, our project management and deployment tools are used by many, many people throughout the community but very few actually work on them. They're used almost exclusively on itself, which gives us a really well-integrated project management tool but also limits the number of people who would be willing to dedicate large swaths of time to satisfy other peoples' demands for features and improvements.

Although some people are willing to chip in on and off, donating time to solving specific problems, actually paying some developers to work on those infrastructure pieces and stick with it over the long haul is more valuable than sporadic work from passionate volunteers.

That's absolutely not the case with every aspect of an ecosystem, and I mentioned in another comment that the leadership of a project is a different beast entirely.


"I'd argue that Red Hat isn't a good example as it was founded from day one as a commercial entity (which at least in the early days did no development of its own to contribute upstream)."

Red Hat isn't the Open Source project, Linux is. Red Hat is one of the major contributors to Linux. They directly employed Alan Cox for 10 years, and still indirectly pay for Linus Torvalds' salary through the Linux Foundation. Not to mention Red Hat's other direct and indirect contributions to Linux.

In other words, I think Red Hat is a good example -- not a bad example. Without Red Hat, Linux would have looked differently.

I don't think that getting paid by Red Hat impacted the quality of either Alan's or Linus' work, or their passion for Linux.

When done wrong, the commercialization of a community project can be something to worry about. However, when done correctly, it can have a really positive impact on the project. The challenge for each Open Source project is to find the right balance.

Soren Jones (not verified):

"Just because you start to pay someone for their work doesn't mean they will work harder, better or more efficiently than the volunteers that did the work before."

While there is not an expectation that paying someone means they will work "harder" or "better", they might, from the community's perspective, work more efficiently.

At DrupalCon Copenhagen 2010, Rasmus Lerdorf was asked "What problems do you see with the PHP development process in general?" His answer started with, "It's a little slow sometimes." And he went on to say, "People tend to build what they need. Sometimes there's a big demand for certain things from the larger PHP community, but if the people capable of building this feature aren't personally interested in it, then it doesn't get done."

Extending what Rasmus said, if people are personally interested in something (the redesign, migrating Drupal version control from CVS to git, etc.) but don't need it today, then it is sometimes done slowly. In such cases, I'd argue that commercialization—paying people—can help make the project more responsive to the needs of the larger community.

Thomas Svenson (not verified):

"The assumption that people are motivated to produce their best work by money is a faulty one.

Obviously a volunteer normally has a much higher motivation to work on a project since that person is making his/her own choice without any monetary factor in that decision.

However, motivation and skills are two different things. You can be the most motivated person in the world, but if you don't have the skills to actually perform the tasks, then the end result wont be good.

That person might, on the other hand, have other skills or resources that is to the projects advantage. If one resource is money, then that person, or company, can use that to hire someone with the right skills to perform the task in the best possible way.

Those who pay someone to contribute back to a community project is obviously motivated, often, but not always, by commercial interests. They are in fact volunteering their resources, just in a different way.

Jeff Eaton (not verified):

I think it's interesting that more discussions around this are occurring. Huge swaths of Drupal are the result of commercial interests funneling resources into tools they needed: performance and scalability improvements, the Views related tools we've all grown to know and love, and huge numbers of support/integration modules.

I think it's also important to distinguish between things like support infrastructure, developer-hour contribution, and leadership. Projects with explicit commercial enterprises "leading" the project evolution tend to have some of the most significant problems in terms of forking and community splits; while Drupal's evolutionary drift has disadvantages it also insulates us from some of the most contentious aspects of infighting over who's in control. Projects that have thrived with commercial interests at the helm tend to be far more focused on very specific productized use cases -- the niches that distros in the Drupal world are well-positioned to fill.


I couldn't agree more.

It's the fact that everyone contributes the things that they think are important or that they are passionate about, that makes Drupal thrive. That is why I'm skeptical about formal roadmaps in volunteer-driven projects. Everyone can help shape the technical direction of Drupal.

It is not so much about how the work gets done. It is more about how the decisions are being made. In Drupal, money is the currency driving a lot of the development, but trust, respect and reason -- not money -- are the currency driving the decision making.

It might be different for other projects, of course.

Rick Blalock (not verified):

Interesting read. I believe jQuery has had some contracted work done on the core library as well. As long as the product gets better, the community is strengthened, and the GPL is not violated - I don't have any issues with contracting out developers to better an Open Source project.

LenZ (not verified):

While this can work quite well initially, there comes a time when a volunteer-based project becomes a threat to larger, controlled organizations (e.g., MySQL to Oracle, Linux to Microsoft).

Actually, MySQL has never been a volunteer-based project - it was started by a company right from the start, with the intention to generate revenue with services that complement the software (which is published as OSS). The majority of the MySQL server code has been created by developers employed by MySQL AB (then Sun, now Oracle.).



You're obviously right, LenZ. Thanks for the correction -- not sure how I missed that. Sometimes we forget that some of the most successful Open Source projects are almost entirely driven by a single commercial vendor. It further illustrates that different models work for different Open Source projects.

The volunteer-driven model excels for projects that are extremely modular and flexible, and that need highly customized deployments. Needless to say, MySQL isn't in that category. Mozilla is somewhat in the middle. Could be interesting to plot all the big Open Source projects on a graph to visualize that correlation.

bertboerland (not verified):

"Sometimes we forget that some of the most successful Open Source projects are almost entirely driven by a single commercial vendor."

And sometimes we miss that such a model doesnt scale well when a company is being bought by an enterprise that is being bought by an enterprise :-(, zfs, mysq, opensolaris....

LenZ (not verified):

Agreed, good modularity and flexibility are key for attracting a thriving developer community, allowing them to scratch their own itches quickly without having to wait for someone else. That's something that Drupal is really excellent in (just look at the awesome amount of contributed modules, for example). It's all about lowering the bar for volunteers/contributors as much as you can.

I also have to agree with Alex UA's post below in that volunteers get discouraged in contributing to "sponsored projects" since there is a different feeling of "ownership".

It is much more difficult to encourage people to contribute or support a project on a voluntary basis, if there is a single commercial entity in charge of it -- there is a certain attitude (or level of expectation) that everything needs to be done and provided by employees of that vendor, since they get paid for doing it.

There is a difference of having a community versus being one.


There is a difference of having a community versus being one.

I agree with your entire comment but that sentence really stood out. Extremely well put, Lenz!

LenZ (not verified):

Thanks! To give credit, the original quote was actually coined by a member of the PostgreSQL community, comparing it the MySQL community :)

I just rephrased it to be generic, since I think it is actually true for a many other communities as well, especially the ones that are centered around products developed by a single commercial entity, regardless of the license that product is being distributed under.

Anonymous (not verified):

I think you should have had someone review this post first. It comes across like commercial, full time people are coming in to take over. The time of the volunteer is passing into the shadows. Just get ready...

I'm sure that's not what you meant. Right?


I did not mean to imply that commercial people are coming in to take over. We certainly don't want that. Our community is our biggest strength.

Alex UA (not verified):

Very interesting post. I couldn't be more supportive of the DA's decisions to pay people to do some of the (hard) specific tasks needed to launch the new d.o. and get D7 out of the door, though I do have some (relatively minor) concerns. My main concern is not that some people getting paid will discourage people from volunteering (I pay people every day to 'volunteer' for various projects), it's that people who are paid will assume more "ownership" over their projects than they would if they were just volunteered. The problem is that paying someone is a form of endorsement by the paying party (in this case the DA), and that endorsement can harden the resolve of the paid project "owner" in regards to their opinion over that which they "own". When we're all volunteers then everyone's voice is more-or-less equal (so long as you have some community karma to burn), but once a person is paid they no longer answer strictly to the community/karma, but now they also answer to the person paying the bills (and they may get a sense of entitlement from that relationship).

Either way, I think the DA has done an extraordinary job in handling this situation- I don't believe that we'd have a newly launched d.o. without making it the J-O-B of a few key community members. Sometimes tasks are simply too important and time intensive to rely solely on volunteer work, and as you point out, many companies (my own included) pay people to 'volunteer' all the time.

As a quick p.s. I'm curious how you see efforts like GVS' Security Report in relation to the DA's efforts. I personally like both types of arrangements (Zivtech happily sponsored the report, as did Acquia), but I'm curious as to where you see the maximum value of that method (a company raising money directly to do something) vs. the method used for the redesign (companies and individuals funding projects indirectly through support of DrupalCon and the DA).

Yannick Warnier (not verified):

I find it funny to think about the concept of having people answering the one who pays the bills, when the latter is an association of volunteers. I hope this, somehow, wraps the whole problem into an aerodynamic ball of paper...

Larry Garfield (not verified):

To clarify, the Drupal Association hired people to help complete the redesign and to work on the Git migration. The Association has not paid anyone to work on Drupal 7. Various other companies have committed business time of their employees to work on Drupal 7 or various module ports (i.e., paid people to work on core), but the Association has not done so.

Yannick Warnier (not verified):

I'm in charge of another type of Open Source project (LMS) where contributions by the first-hand users (teachers) are *very* low (although a few exceptions remind us not to forget about them).

However, the project itself is reportedly immensely useful to a huge number of teachers. In many case, these are public sector teachers, who already struggle to get some time for themselves, so they tend to have difficulties contributing, and when they do they still have to pass over a technical barrier to "report a bug".

For us, having the project based on paid people is a necessity (which I am personally not comfortable with, but I've had to learn to deal with it for the better of all).

Drupal benefits from a huge easing factor in comparison with us: a lot of users of the software are also web developers (in the broad sense of the term), which means it *could* (theoretically) be based on pure voluntary work, if we were talking about development alone.

However, if you want your project to grow, you will need reliable building blocks that will do any job that must be done, not because they like it, but because they're being asked to do it and they understand the need to do it. Boring tasks tend not to be overtaken by anyone (as I understand Rasmus was suggesting), yet they are often necessary for the pure volunteers to be able to create more, more easily.

Like in any metal alloy, it's a combination of various components that make the better structure, but the mix has to be the right one. The perfect balance can only come from experiments and errors, sadly, as there is no clear procedure established for that so far... or maybe there is in other types of structures like MSF and those kinds of ONGs, but finding someone willing to study that model voluntarily might be a challenge.

As Drupal is leading the way in a few aspects in the Open Source world (list of contributors, size of events, number of companies involved), I hope it will succeed and explain to others how to do it right. This is a fundamental step in the evolution of Open Source Software: making it easier for volunteers to contribute while making it a living for jobless people ...

This is why I find this discussion exciting, somehow!

Zy (not verified):

I read this post and agree with Dries, it might be that volunteers does not have the competence in what they are doing and that is, sometimes it is better to hire someone who has the competence in particular topic to speed things up.

Anyhow ... it's all about quality not moneys.

Amy Stephen (not verified):

"For example, Joomla recently hired some developers to work on their core software, a decision that has caused much debate in their community."

To be honest, the debate in the Joomla! community was less about paying developers and more about the need to open up our Open Source Matters foundation which had sort of invisibly morphed from a "minimal existence to satisfy NY state's legal requirements for a corporation" into "corporate headquarters."

Many significant decisions, including a new trademark and policy, hiring developers, were made without community involvement. At that time, there were no agendas or minutes shared, and the outcry you saw from the community was a plea to engage the community in governance.

Since that time, the Open Source Matters board has been transformed. In February, Ryan Ozimek became president and several new board members joined. Recently, seven more were added. The change has been extremely positive and the community is growing, as a result.

Personally, I would recommend Drupal continue to fund development through the arrangement of private sponsor agreements that only involve the developer and the individual whose work is funded. It's easier. Easier means less drama. Less drama means more code and productivity. Don't mess with it if you can avoid it. I truly believe it's not worth it.

But, if you do pursue contracts and paid development, be clear about expectations. Don't leave work open ended, and carefully plan reporting and oversight. That's another mistake made and correcting a lack of accountability is not easy. If work can be quantified and quality measured and there is an absolute start and end date, it makes a better candidate for staffing. IMO, though, contracting developers for normal work activities isn't a good idea. That's where community volunteers shine.

My advise - don't do it. But if you do, proceed with extreme caution and be open.

K (not verified):

Couldn't agree more with your position Dries. I see no problem using DA funds to pay for commercial work, especially given that I would never have worked on Drupal had SF State not paid me to compare it to other content management systems. Now, Drupal is taking over the campus web infrastructure. I'd take it further though and say in addition to using these funds to hire people for getitng stuff done, there should be no problem buying more hardware with those funds to solve problems as well. Kieran was just talking last month at SF-DUG about how he was giving a sales presentation and for the x time was unresponsive or slow again. So, he said that (I forget if it was him directly or Acquia), that one of them whipped out the money to just go buy some more memory for the servers. I think we need more of this attitude, sometimes it is necessary to pay for something to get it done, even if it is out of our own pockets.

yvesHanoulle (not verified):

If I look at youth clubs in Belgium,the bigger ones all have staff. The staff works on the organizational aspect and they sometimes help out when volunteers don't show up.

Companies should focus on their core added value. That is the same for Open Source projects. In a sense I think you have "always" used paid services, from the moment the Drupal community did a conference in a public place, you hired a conference room and all these extra services. I don't think they are seen as "paying people to work on volunteer-driven projects". Why not? Because it is not the core of the Drupal.
Doing the same in the CouchSurfing community would probably give similar nervousness.

For me it is not so much about paying people, but about the work they are doing. As some people have said in the comments, if there is a big real "client" need, and no-one interested with the right skill set (or the possibility to build the skill set in the right timeframe) that could be the moment to pay people.

I would prefer the solution as Thomas said:

"Those who pay someone to contribute back to a community project is obviously motivated, ... They are in fact volunteering their resources, just in a different way."

If there is a real client need, companies that work for these clients (like Acquia) could fill that gap.

It raises the questions if the Drupal community prefers to pay themselves or these companies pay. Or better, who is in control of what is done.

When I develop as a volunteer, I select on what I want to work. When I'm paid as a developer for an Open Source project, should the community decide or the company that pays me (and has a real itching client need.)

If their is a something to be done that is very important to the community and nobody wants to do it, and no supporting companies are interesting in paying for it, that is an interesting situation.

Si Chen (not verified):

Great post. I wish it wasn't necessary to explain oneself like this any more, but as long as it, please tell the story.

This quote I found particularly compelling:
Some projects can't afford not to make use of the benefits that a full-time, focused staff can provide.

Once a project is large enough and enough people derive value from it, there is a justification for paying people to do it. Even if open source gives away most of the value, against a large enough community there will be enough value left to hire paid help. If that's the case, then by all means do it.

Pierrick (not verified):

Very interesting topic Dries and I think it's smart and courageous to open such a discussion, considering your position between Drupal and Acquia.

Overall I agree with Dries but I think he also sounds a bit optimistic. I agree that some pieces of work won't ever be made by volunteers and this is a very good thing to get them done by paid staff. But on the other side, some volunteers just do not accept that their work can generate revenue to someone else. Everything is fine as long as nobody earn money but when someone is getting paid for doing a task related to the project, some volunteers just don't appreciate it and may stop contributing.

I also think it's just impossible to make everyone happy at the same time. So you have to make some choices with the projet evolution in mind. Improving was important and I'm sure the result will improve the feeling you get when you meet Drupal for the first time. I'm nearly sure that not many volunteers wanted to work on this project because they were already in love for Drupal, so why wouldn't anyone be like them? But the new site is an important step and working with paid staff was the good decision in my opinion.

I'm also leading an opensource project (much smaller than Drupal, but significant), community driven, started 9 years ago. I've decided to make it my full time job now and that implies I'm going to make money while other team members and plugin/themes contributors won't. And believe me, while some core community members are in favor of my choice, some others are not that happy...

Brian Teeman wrote:
> Just because you start to pay someone for their work doesn't
> mean they will work harder, better or more efficiently than
> the volunteers that did the work before.

I would even say that he would work less but that's not the question. In my opinion, the true question is "would the volunteer have worked on this task that nobody want to achieve?". If you have a community with great coders but nobody to make the website sexy and attractive, then what should you do? keep an ugly website and reject lower skilled user? no, you pay someone to make the website attractive and that's the right thing to do.

Anonymous (not verified):

Interesting post Dries and I whole heartedly appreciate the post and your honest effort to justify the DO redesign to the community. I am very happy to see DO bloom with the new design as a great fan of Drupal.

But interestingly very sad because the community the strength of Ddrupal has failed to understand the reality of todays competition with other competing CMS and failed to contribute for their very own love Drupal.

I am not aware of how the decision was made but for me it is very hard to believe that no competent person/org found who could do better than what the paid person/org has delivered for us the Drupalistas who made us believe that Drupal is the best in the world of CMS and wanna be the leader by out compete other CMSes.

Elin (not verified):

Very thoughtful post Dries.

Just to clarify (and I know you know this but others may not), Joomla! hiring developers was the opposite of commercialization; it was done by a non profit for the purpose of producing software that is given away. This is no different than a non profit hospital paying doctors or the Red Cross paying the people it pays to do disaster relief (or perhaps more important the people preparing for disasters in the future), or a religious institution paying a member of the clergy. There is nothing about any of those things that makes those things commercial.

I think what you really mean is, when money comes into play it's complicated, and I'll agree there. It's always a challenging transition (I'll say with my sociology hat on) but is one that almost all non profits that survive more than three or four years go through. Just a standard part of the organizational and social movement life course, and the kinds of software projects that start with volunteers (as opposed to those that start with a consortium of companies for example) are in my view both social movements and organizations.

While some think that it would be beneficial for there to be a single large commercial company dominating the Joomla! space, others, myself included, feel that, instead, a non commercial model is worth trying to sustain.

Is it possible for non commercial core production of powerful software to exist in the midst of a dynamic and diverse commercial ecosystem of application builders, site developers, templaters and others around the world?

Could it be that producing the core software non commercially in fact enhances the ability of those small companies to survive?

Does ensuring that there are extremely high skill people doing work that is not always fun and is often frustrating, involves way more planning and management and consultation than the joy of writing code, week in and week out, make it possible for lots of companies to get financing or to make personal investments of time and money in building their businesses?

Does knowing that they don't have to hire staff to task with working on the core, wonderful and welcome though that would be, help businesses that might only have 3 or 4 employees?

It's an interesting set of questions, but so far the results have been positive.

The expectation that people writing software should have to make a choice between carrying essentially a second full time job (and not ever have children or spouses that they might like to spend time with or who might need shoes and not maybe want to go to a movie once in a while or even have a hobby that isn't software related) or choose live in poverty by cutting back their paid work time to allow them to work 30-40 hours a week without pay for a lifetime to be bizarre. In fact, about the comment that people work less hard if paid ... if pay introduces a culture that prevents burnout then I think that is a good thing.

It's one thing for people who are starting out, but five years out it's just not fair to have those expectations. Add to that the pressure of making it possible for small development firms to get paid to build sites, and Viacom to build sites, and the House of Representatives to build sites, and eBay to build sites, for support services companies to make money, template companies to make money and so on and it is just not sustainable long term.

The differences in how this is playing out largely reflects the very different ecosystems and softwares that are Drupal and Joomla!. While Drupal Association is investing in administration and organizational infrastruture OSM has focused on development. The DA can do this because it does have people who are paid by companies to develop for the core and also because the barriers to entry for Drupal development businesses are higher and of course it is much more highly centralized so there is just a different relationship there. What may be true is that there are fewer people to do some of the organizational work day in day out. In Joomla we have lots of people who are good at doing organizational work, but development is so decentralized and the code is so modularized that only a tiny minority of extension developers (custom or retail) ever add libraries or modify the APIs or change the core CMS. The Joomla ecosystem is perhaps more like that around FireFox or maybe the iPhone (there's an extension for that), the Drupal ecosystem is more like perhaps Apache or even Linux (companies realizing it makes economic sense to contribute). What I can say for sure is that neither is like OpenOffice or Symbian. For that we all have reason to celebrate.

Kit (not verified):

Time is money - money is time ?!

I can discus and or argue about the fact that money makes people more or less involved/devoted etc. with or to something or some one.

How ever bottom line to me is & what it all comes down to is that ; money buys you time and time gives you the opportunity to increase the skills & the product/project.

A volunteer has to find or make time in order to be able to contribute, each minute they spend time they make a huge effort and are as i believe completely focused on/to what there doing. Some volunteers seem to lack some skills, yet is that really the case ? ....Perhaps its just a lack of time.
The more time they can spend (quality time that is ) the more there skills can become visible and yes the more there skills can develop/increase/grow
and there for the product/project that there working on can do to!

Money always was/is and will be a factor & a risk
Positive or Negative ?
That is up to the community; if positive the community will support, if not then sooner or later the community will abandon
its as simple as that !

Volunteers ROCK !
embrace and Charis them
for they are the key

Ric Johnson (not verified):

I must say that this is the biggest issue I have had trouble understanding in Open Source.

If WordPress has an IPO, then how exactly do the people that have contributed over the years also receive just rewards? Is it fair that they asked for donations for years and now they will generate a profit? Yes - they provide additional services. And other 3rd parties can charge to install / theme / develop modules, so why can not Automattic?

Perhaps I have been in closed source for too long, but why can not a project be run like a corporation? That is - pay everyone efforts in stock, and when the software is successful, then everyone benefits.

My other serious question is the choice of license. Would you ever decide to have a dual license, so some corporations can use Drupal with (slightly) modified terms? If they paid, then that would also sped the adoption in two ways.


Your comment is a bit all over the map so let me break down my answer:

  • WordPress (the project) itself can't IPO, but Automattic (the company) could technically be a public company at some point in time. This is not unique to WordPress; it is true for Drupal as well.
  • Every Open Source project has a different government structure. There are examples of Open Source projects that are run almost exclusively by one company. For example, I'd guess that 95% of the contributors to Alfresco (the project), are employees of Alfresco (the company).
  • Drupal is GPL. The GPL does not allow the terms to be changed, not even slightly. A dual license strategy for Drupal seems extremely unlikely because copyright is distributed amongst hundreds of contributors. All contributors would have to agree on a dual licensing strategy.
Ric Johnson (not verified):

Thanks for replying.

Maybe my question was confusing, let me see if I can be clearer.

The WordPress project has accepted donations as well as lots of code and support for years. Now, Automattic will have an IPO where only a few core people will be rewarded. I know that anyone can use the software for free and that Automattic provides much more than just hosting, but the truth is that they would not exist if it was not for their community. Do you think this is fair? Can we ask the community what they feel about this? Would it not be more honest to let everyone who has contributed to be able get some stock?

I am a windows developer as well, and I see this also happening in DotNetNuke (the #1 open source project in .Net). The last few releases of that project were mostly features that they charged for. Do you think there should be a certain percentage of effort that a corporation that is driving a project should guaranteed as not for profit?

I LOVE Drupal - but unfortunately the license prevents me from using it in some projects. A dual license would increase adoption as well as pay for development. What do you think of this model? Suppose someone is willing to offer millions of euros, just for the right to not have to publish their modified source. This money would be fairly distributed to everyone that has worked on the code. May we ask the community if they would prefer that?

Freso (not verified):

A dual license would increase adoption as well as pay for development. What do you think of this model?

As he already said: no matter what Dries thinks of this model, you'll also have to convince the hundreds (we haven't reached the thousand yet?) of contributors holding copyright to the code (which would most likely also include all of contrib land (contributed modules, themes, etc.)). Some of these people are no longer in the Drupal community. Some (may?) have passed on the other side. Some may be in areas of war or other turmoil. All of these people will have to agree to change the license. If you still wish to work on this... happy hunting and good luck to you, sir. :)

Suppose someone is willing to offer millions of euros, just for the right to not have to publish their modified source.

If they're willing to shell out that kind of dough, feel free to contact me, and I'll be sure to make them a deal. ;)

Seriously though, if you make modifications to the core code (which you most likely really do not need to do), you are free to not publish the modified source. As long as you do not redistribute/share the code, you are free to not publish it.