I’ve been using Drupal for a number of community websites for the past year. Overall I quite like the system and how customizable it is.
What I’m not really thrilled by is the way the module structure exists on drupal.org. The problem is that drupal core is a very small number of modules. The bulk of useful functionality comes from user contributed modules. So far so good, many projects run the same way.
The real issue is that the drupal project maintains a centralized CVS infrastructure for module developers. There is a pretty formal process to get accepted as a module author, and no real way to get CVS access to just fix bugs. The net result is that after finding 3 bugs in the date and callendaring modules, creating patches for each on my own environment, and submitting them upstream, only 1 has gotten looked at. The fixes were submitted about 8 months ago, and I’ve pinged a few times. I also wrote the author directly on one of the modules.
The root cause of this issue is that drupal has centralized infrastructure, but decentralized decision making. It is a classic community wherein github would be a good solution.
I’ve been an absentee maintainer before, I know that sometimes interests change, and you move on to other things. But at least with something like github, other folks can very easily extend what you’ve got and make the fixes themselves. Hunting out RCS style patches in drupal discussion forums is just really problematic. At this point I’ve got quite a number of local fixes, so module upgrade and maintenance is tricky. The only saving grace is that most of those fixes are on modules that are effectively abandoned so I shouldn’t have to worry about an update coming down the pipe.
The Drupal community is soldiering on even with bad developer infrastructure. I just wonder how much further along they’d be with better developer infrastructure.
It's always more complicated 
If you deal regularly with a locally-patched piece of software which may get updates from upstream, and you’d like to upgrade versions without losing your local changes, then nothing beats throwing your software into version control, creating a vendor branch for the official software, and checking in your patches on the main line. When new versions come out they apply cleanly to the vendor branch and you are a simple git merge away from updating your working code, local patches in tact.
LikeLike
The biggest challenge is how often those upstream changes come down, which has been typically a couple times a week.
I’ve got a new approach which is going to be kind of ghetto version control based on the release bundles in drupal. Got to write a bit more code to make it work.
LikeLike