A method for giving credit to organizations that contribute code to Open Source

If we want to encourage more organizations to contribute to Drupal and hire core developers, we should start to give them credit for their code contributions. I'd love to see us maintain a page on Drupal.org that shows which companies contribute to Drupal and in what capacity. This credit provides these organizations a tangible benefit in recruiting developers, demonstrating their expertise, and more. Credit is a powerful motivator for individuals, but also for businesses. It is a form of trust currency.

It is great that we give individual contributors credit for their code contributions, and we should continue to do so. However, I'd like to extend that to organizations, both to the Drupal agencies as well as their customers. Mapping out how code contributions get funded can be great for individuals, customers and digital agencies.

A great way to start doing this, is to adopt a new format for Git commit messages. I'd like to propose the following format:

$ git commit -am "Issue #n by INDIVIDUAL@AGENCY*CUSTOMER: message."

We prefix agencies with @ and customers with *. I believe this provides us the necessary flexibility. We could choose to store this in Git Notes, if we prefer, but that is not the main point.

Contributed a feature as an individual consultant directly for a customer or end-user:

$ git commit -am "Issue #n by INDIVIDUAL*CUSTOMER: message."

Contributed something in your spare time and don't want to give credit to your employer:

$ git commit -am "Issue #n by INDIVIDUAL: message."

Let's put it all together with a real example. Imagine Sam, Megan and Tim collaborated on fixing a performance bug. Sam helped in the "20% time" provided by her employer Acquia, Megan helped in her spare time after work, and Tim worked on this on behalf of his employer, Pfizer, who is affected by this bug. Ideally, the commit message would look like this:

$ git commit -am "Issue #42 by Sam@Acquia, Megan, Tim*Pfizer: fixed performance bug."

The great thing about this approach is that we can adopt it today and worry about analyzing the data later. It also works regardless of where your Drupal code is hosted (Drupal.org, GitHub, etc) or what your source code management system of choice is (Git, SVN, etc). In fact, I believe all Open Source projects would benefit from this level of transparency and that giving credit directly into the commit message makes it very transferable.

If adopted, we'll want to build tools to help us create these commit messages (i.e. have contributors provide proper attribution in a new project issue field so the maintainers/committers don't have to manually create it).

With this level of transparency, we can start to study how our ecosystem actually works; we can see which companies contribute back code and how much, we can see how much of the Drupal project is volunteer driven, we can better identify potential conflicts of interest, and more. But most of all, we can provide credit where credit is due and provide meaningful incentives for organizations to contribute back to Drupal. I believe this could provide a really important step in making Drupal core development more scalable.

I'd love to hear your thoughts about us giving organizations credit.

Update: this was rolled out on drupal.org in 2015. Instead of providing the credit in a Git commit message we built a user interface for it.


Damien McKenna (not verified):

If a field is added for comments that allows the contributor to indicate whether who the work is being done on behalf of, what happens if there are multiple values? Would the commit message change to "Issue #42 by Sam@Acquia, Megan, Tim, Tim*Pfizer: fixed performance bug."?

June 04, 2014
Joshua Mitchell (not verified):

I'm for this sort of community credit on several levels. It would give us a great way to highlight the organizations that are contributing code and encourage more organizations to fund important work in core and contrib.

Once we can parse this data, it gives us an excellent way to give community/social credit to developers and organizations. This will help organizations and individuals to grow in the community. That growth will help with hiring and getting hired. Further, this ties in very well with our profile initiatives on Drupal.org—both personal profiles and organizational profiles.

I like the suggestion that we start collecting the data as soon as possible so that we can begin testing ways to parse and store this information in Drupal.org.

June 04, 2014
Jeff Walpole (not verified):

I agree. We need to make this "trust currency" (great term btw) something prominent on both an individual and organizational profile including the marketplace pages. There are many ways to give to Drupal but right now contribution is not well displayed for organizations (and people). I would like that to be at the top of a profile letting you know the "stats" of contribution. Maybe similar to how a twitter profile page lists "Tweets" | "Followers" | ""Following".

June 06, 2014
Mike Gifford (not verified):

This is a terrific idea. I do think it is something that could really inspire some organizations to contribute a more. I like how it's flexible enough to credit individuals, shops & also the end client.

The true value however will come with how we aggregate this data. If we do a good job of that and feature it prominently on d.o it will have a good impact on community engagement.

June 04, 2014
Peter Vandenabeele (not verified):

In a previous venture (mind.be, acting as an agency in your proposed model), we submitted some contributions to Linux.

A specific case was that our (large brand name) paying customers allowed or even asked us to commit back upstream, but also, did NOT want their name mentioned at all (so they where effectively paying for open source development, but preferred secrecy over their contributions). They had no problem with us (the agency) taking "credit" for the contributions.

Practically, that means I will expect your model to often feature:

Issue #42 by zombie@mind*anonymous

An alternative that could use less space in the commit message is to use a uniform #sponsor tag:

Issue #42 refactor user model #sponsor acquia



June 04, 2014
greggles (not verified):

Seems like a great proposal to me.

I've added to my profile a string that people can use for any patch I contribute: greggles*card.com

I plan to start doing this for any modules I maintain.

I encourage people who look at other metrics to figure out how to get information like this into those areas. For example, we could consider noting information like this in Security Advisories as well.

June 04, 2014
Robbie Holmes (not verified):

There is a project that has been around for surfacing the contributors to core : http://ericduran.github.io/drupalcores/ this is updatable to contain new and interesting structured data.

June 04, 2014
Anonymous (not verified):

What about agencies with multiple words in their name? Still add the natural space and leave the commas as delimiter?

$ git commit -am "Issue #42 by Sam@Commerce Guys, Megan, Tim*Turner Broadcasting: fixed performance bug."

June 04, 2014
Bryan Braun (not verified):

I think this is great! It's a simple adjustment, but it opens the door to a lot of opportunities. Lets start using it, collect data, and think about ways to visualize it so that both individuals and organizations can be championed for their contributions.

BTW, I'd be all for a page on Drupal.org that highlights contributors and organizations. I agree... http://ericduran.github.io/drupalcores is an interesting prototype of this kind of functionality.

June 04, 2014
Tim Holt (not verified):

+1 to this idea, I think this is a great way to provide real visibility into who is involved in development on d.o. And since it's optional, companies that aren't comfortable with this can still sponsor dev and be left off the messages.

June 04, 2014
Ian Thomas (not verified):

I'm for something like this, but I think it does need to be in git notes, or at the very least after description of the commit, as that is typically what you're interested in when scanning a list of commits. For example, cgit's list of most recent commits on D8 includes:

Issue #2248799 by amitgoyal, Wim Leers, c31ck, joachim: Fix docs for system_s...
Issue #2103039 by fran seva, rodrigoaguilera, Gábor Hojtsy, ifrik, batigolix...
Issue #2091429 by amitgoyal, mparker17, batigolix, Mark Conroy: Update hook_h...

...which isn't very useful.

We don't want to make that problem worse, and as you say, once the data's there it can be extracted into pretty graphs etc. I think git notes can be amended at a later date too, which would allow a sponsor to be removed from the git history if they had been added without their permission.

June 04, 2014
trouble (not verified):

Oh, you mean like what the BSDs have been doing forever with "Sponsored by:", "Obtained from:" etc in revision control logs? Only in a more obtuse format?

June 04, 2014

I wasn't aware of what BSD is doing but will make sure to check it out.

June 04, 2014
SebCorbin (not verified):

There is a big question: how do we manage that on a regular basis?
Let's say I'm the maintainer of some module or even a core maintainer, do I have to ask each one of the issue participant who is he working for and what client/project on, each time I wand to commit something?

Sound like a lot of work...

June 05, 2014

I tried to address that in the post. We can easily add a field to project issues and ask each contributor to specify the proper attribution. That way, the maintainers/committers don't have to do manual work.

June 06, 2014
Kevin Oleary (not verified):

This is an awesome idea. I think it will rally begin to have an impact when the aggregated statistics are presented publicly and prominently and organizations start competing to be the most generous.

June 05, 2014
Kevin Reynen (not verified):

The cynic in me half expected the system of recognition to involve becoming a Acquia partner first, but this is eloquent solution to the complicated problem of crediting a developer's more enlightened patrons... organizations less concerned with tracking every billable minute who understand the tangential benefits of letting developers perfect their craft. There was a time when names like Archbishop Colloredo and the House of Medici where as well known as the artists they funded. Today, the patrons are only remembered by art and music historians and trivia buffs. The recognition of benefactors is something both the arts and higher education still do well, but for some reason it seems completely acceptable to graduate with a degree from a [INSERT (DEAD|STILL LIVING) RICH, WHITE GUY'S NAME] School of Business or Management while wrong to use the Sony Views module. I'm sure that just reading that anyone would suggest giving Sony naming rights to the Views module made someone's blood boil. I have no idea how much or how little Sony contributed to Earl's work on Views while he worked there. I just used that example to get people thinking about how much or little they might contribute to a project if it already had another company's name on it.

An obvious next step is to display commit credits on organization pages which is already being discussed (https://drupal.org/node/1966218#comment-8784711). This seems all too logical until someone says, "organizations are shoudl be people and have user accounts too". That phrase should set off alarm bells with anyone involved in US politics. We have just entered the second phase of Dr. Lessig's (of Creative Commons fame) attempt to buy back our democracy by raising millions for the Mayday PAC to end the flawed idea that rights can be added to organizations as people without reducing the rights of real people.

Even creating new tools to add "a new project issue field so the maintainers/committers don't have to manually create it" has to be weight against the potential problem of 'contrib credit spam'... orgs that make minor improvements to a patch just to have their org name included in the final commit message.

Giving credit where it's due can be very subjective. While structured commit messages can provide data that helps find truly enlightened patrons of development, any system that tries to completely automate the credit will likely be gamed.

By only suggesting the Drupal developers adopt this pattern when committing, it still requires a developer to think about who to thank or give credit to when making the commit. Tools that make it easier to give credit also make that credit less meaningful.

June 05, 2014
Rick Manelius (not verified):

I know there are larger implications with this suggestion, but hosting on github would give an additional and automatic credit to the author.

June 06, 2014
Yonas Yanfa (not verified):

I also think it should be in git notes, eg. "Sponsored by:".

I'd prefer the commit message not contain anyone's name. At the very least, we should put it at the very end of the commit message. but ideally, we should get into the habit of putting those into git notes.

June 06, 2014
Achton (not verified):

I really like this idea, and I think many more things could be done in order to expose the names of individuals who participate in developing features and fixing bugs.

I am also curious (as Seb Corbin above) as to how this will be coordinated practically in the issue queue? Seems to me that every issue thread would end with the commiter going:

"OK, I'm ready to commit - Sam, Megan, Tim, please state the client and/or agency you would like to attribute this patch to."
.. [wait n hours/days for Sam, Megan, Tim to reply]

How about integrating this into the issue comments themselves, so that when people post comments/patches as part of such an effort, they can provide those data for each comment.

Sometimes an issue may span many months and not all work by the same individual is done for the same client (or even agency). So it makes sense to discern per comment in what capacity the work was done. This could then be summarized (aggregated) automatically in the issue header/footer/wherever for consumption by the committer.

June 06, 2014

Glad you like the proposal! I agree this can easily be fixed with some extra tooling.

June 06, 2014
Jürgen Haas (not verified):

Like the idea and maybe the project_issue module on d.o could be extended so that contributors of an issue (including the original reporter) could easily tick a checkbox if they want to be given credit and if so, for which organisation. If that detail was present, dreditor could then collect all that stuff when using the function "Create commit message" - that would ensure consistancy and easy of use for maintainers.

June 06, 2014
jhodgdon (not verified):

This seems like a fine idea!

But we really have to be sure that it does not make more work for maintainers who commit patches. A field on the issue sounds good, but what if someone who makes a patch or spends time reviewing a patch (and who should then be given credit) doesn't fill in the field -- do they not get any commit credit? What about the thousands of "legacy" issues we have, which do not already have this field, but still might very well be committed after this takes effect?

I'd also make a plea to make sure the solution does not require dreditor. As a core maintainer, and maintainer of other modules, I should be able to get the job done without it, if my personal preference is not to use dreditor.

June 06, 2014
Yonas Yanfa (not verified):

If we implement a new commit tag for Drupal.org comments, we could automatically print contributors:


We already have a bot that links to new commits in the related issue. With a new commit tag, we can have the bot also print the contributor information.

June 06, 2014
Jeff Walpole (not verified):

+1 and great conversation, sounds largely positive with some clear path forward. Next up would be how to display the data we collect.

June 06, 2014
Anoop John (not verified):

This is great idea.

In the context of a developer leaving an organization and joining another, the former organization could continue to get credit for the contributions done by the developer while at that organization. In the past the developer could move on with all the credit while the organization would get none.

What about allowing organizations to create user accounts (an organization user - could be a different user type / role) on Drupal.org and then the commit messages could just have the username of the organization in the message. Clients who wish to claim credit could create organizational accounts as well while those who don't want to claim credit need not.

The trust currency report would also be a good tool for developers to convince managers who might otherwise not allow contributions to allow them. So getting that live would help speed up adoption of something like this and drive organization level contribution.

June 08, 2014
Kevin Reynen (not verified):

While I support giving organizations the credit they are due, I'm against any change like giving an organization a user account that makes organizations more like people. Treating organizations as people has been very bad for democracy for the same reasons it would be bad for an open source project like Drupal.

June 10, 2014
George DeMet (not verified):

Echoing what others have said here, this is a great proposal. What I like about it is its flexibility, plus the fact that it enables providing credit to the individual, their employer (who often supports their community time), as well as the client sponsor.

We often credit clients who support work on various modules on the relevant project support pages, but there's currently no consistent format for doing so, and it's not easily trackable. This proposal seems to address those issues, and I'd love to see it (or something similar) become part of the Drupal.org roadmap.

June 09, 2014
Larry Garfield (not verified):

We can quibble about the implementation details, but overall YES PLEASE!

In order to be successful, the key factors IMO would be:

1) Developer posting a patch or a code review can case-by-case mark "this should also be credited to [employer] and/or [sponsor]." Because a given issue may span many people, companies, and time periods it should be on a per-comment basis.

2) Whatever the process is for generating the git commit message/notes, it should be largely automated off of the above information in the thread.

The big blocker in the past for more robust tracking (eg, separating "patch coders" from "patch reviewers", as has been discussed before) is that it raises the workload for committers, which means it often wouldn't get done. Maybe that's as simple as enhancing Dreditor a bit, or maybe it means Dreditor-esque functionality should be baked into the issue queue directly. I leave that to the infra team to sort out.

Another factor: Spelling consistency. :-) Some companies have names that are often abbreviated, or may be said in different ways. Eg, my employer is legally "Palantir.net", but often referred to as just "Palantir"; Similarly, I couldn't say off hand if it's "Phase 2" or "Phase2". we'd want to minimize the potential for that to "split the vote" for a company that's trying to contribute. This is probably also easily solved with the right tooling; we just need to make sure we build that right tooling.

Repeating: Yes please!

June 10, 2014
Matt Mullenweg (not verified):

Very cool idea. Been considering something similar for WordPress except it'd be part of profiles instead of a commit-level distinction. Not sure how you measure contributions before and after, but hopefully it encourages much more participation.

June 11, 2014
Rob Gill (not verified):

Chiming in late here, but I'd also throw my support behind this idea. We have a lot of developers that contribute as individuals but we currently do not contribute as a company. What I like in this approach is that our individual developers maintain their identity within the community, but at a code level the work can be associated with the company. A less elegant alternative is multiple drupal.org accounts (robgill, robgill_nbcu for example), not very sustainable/manageable. It allows individuals to join/leave companies and continue to maintain their modules as robgill. It also allows the company to maintain that trust currency (like that term).

June 11, 2014
vijaycs85 (not verified):

+1 for this proposal. Hopefully crowd fundings(like drupalfund, gittip) can be covered as organisation or customer.

June 28, 2014
PWolanin (not verified):

So, I think the implementation details actually do matter here.

The git commit message is immutable - and it's not something we'd want an automated system creating necessarily.

However, it would be possible to add git notes to past commits and even have issue queue automation to add notes to commits after they happen.

July 06, 2014

Updates from Dries straight to your mailbox