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 .
- 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
- 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?”.