Moderated API contributions for drupal
More and more, drupal site builders have to make choices that they shouldn’t if it comes to “choosing which contrib to use”. We often can choose for an API - which is great - or choose for a ready-to-go module. As a developer, I will choose most of the time for the API. The problem here is that several API’s are available. E.g. Friendlist, User Relationships, flag_friend, (buddylist), … all great modules that will end up doing the same thing: connected drupal users within a kind of relation.
I recently want to use a XMPP framework in drupal and even there, i have several options. (DXMPP, XMPPframework, and some others). I myself made the same mistake with heartbeat while activity2 module existed. Why? Because website builders and implementers always have to create a site, and it’s known of sites that we have to rush to get it done within the time we get. So we don’t want to be too quick in deciding but we can often not test it all out.
That said, wouldn’t it be great if we did not have to make this choice. If drupal contributed modules could be moderated as severe as drupal core, we would end up in a nicer and leaner set of drupal modules. Lot’s of API’s, I’m sure, but it would be a big step forward imho. I have the impression that the drupal community is so great that there could be a way to moderate API contributions .
Advantages:
- Choosing a module would be very easy if you already know you want an API (as dependency in your own project)
- Features request, debugging and programming in general would speed up because more people can work the same project in stead of being scattered amongst several projects.
- When a new version of drupal comes around, forces can be bundled again to port the API’s.
- Much cleaner roadmap and issue queue
Disadvantages:
- Developers freedom is a bit restricted
- Features requests can take longer due to discussions. (One of the main reasons several contributions with the same purpose exist in the first place is the fact that you need that exception that is “just not there”)
- Communication between developers may slow down because there are more of them, different timezones. A lead developer role per API could cover this.
This blog post is part of the open question “Which road must drupal take?”.
April 26th, 2010 at 3:08 am
Boo. If I want to create a module that does something similar to but not the same as another module, I should be allowed to do that rather than told to add it as a feature to some existing monstrously (and unnecessarily) huge API. The Drupal community is about openness. Better to have a wide choice than a poor choice.
April 26th, 2010 at 3:53 am
As the maintainer of the largest contrib module in Drupal, I can tell you that a LOT of people moderate core Drupal and the amount of code and activity in all of contrib is at least a hundred times that. There simply aren’t enough resources to moderate all of contrib meaningfully. All that would really happen is that people would move their stuff off-site where they can work more in freedom.
Even more, Drupal itself can be community moderated because at least the moderation that happens is because Dries and the branch maintainers share a vision. Can they say that about my module? How are they supposed to know anything about Views?
And would Views ever have happened with a moderated contrib? I don’t think it would have, at least, not the way it has. Maybe I would’ve done something offsite, but I would have been so frustrated with the politics of trying to push something through moderation that I feel confident I would’ve stopped trying and gone elsewhere.
April 26th, 2010 at 1:33 pm
Thx for the great replies. That was my point exactly when creating heartbeat. So with your experience in mind, the best way is to let people develop freely without any moderation boundaries.
Thx again!
April 26th, 2010 at 9:50 pm
Unlike the others, I agree with your considerations here.
We do not need yet another duplicate module that provides the same functionality as module XYZ, just because you added a configuration option for setting Foo.
Likewise, we do not need a new “List” module, that is Views, in pink.
We opened the review process for new CVS applications some time ago, so everyone is able to help in moderation of (entirely) new projects by new contributors, who actually are guilty for most duplicated projects, modules, and efforts, unfortunately. Everyone can help to review code and point applicants to existing projects in the http://drupal.org/project/issues/cvsapplications
However, the fact that we frequently need to point people to existing projects and tell them that their work totally duplicates an existing module and therefore provides zero benefits for the community, means that we failed to provide sufficient measures to allow users and developers to find existing projects on drupal.org.
Working heavily in core and contrib, my current conclusion and feeling is that we fail to apply Drupal’s community idea and Drupal’s principles to the sphere of contributions and into the minds of people that did not attend a DrupalCon yet. The principles of joining forces to build better products, collaborating in an open and friendly fashion, thinking both small and big, … are all not understood.
April 26th, 2010 at 10:36 pm
I was not specific enough in my post as well. I saw this a bit like this: When creating a drupal contribution, we have the option to label the project as an API. The only difference would be that this type of module is moderated/managed differently (as severe as several developers together can be).
This way ready-to-go modules and even smaller api’s that don’t want to be labeled this way can still go ahead. The choice should indeed be left to the maintainer.
What does the label API do then? Time will tell. Could be a “recommendation”? It sure wouldn’t be left without maintainer that easily. Is it this what developers need to make a choice on how to proceed in their own projects, wanting to set a “default api”?
The sollution could satisfy both worlds. What i hope would happen is that some maintainers will end up labeling their module as the API to go or new api projects could be created in a collaboration of developers to merge and filter the best of several api’s.
Maybe i should have taken this discussion at drupal.org …
April 26th, 2010 at 11:28 pm
API category on drupal.org:
http://drupal.org/node/113412
April 27th, 2010 at 12:10 am
Great,thx, I’ll take the discussion out there.