By nonrate on

Hate to be a whiner, but I got to whine.

I was going the route of building my own CMS system for my customers, but led myself to believe systems like Drupal and Worpdress have matured to the point where I was just duplicating efforts. Well, they have matured very well indeed, and Drupals advanced user and permission architecture is no doubt the best I've found.

My complaint is not with Drupal, but the development practices of many of the modules.

For example, the Asset module in 6.x yields this result when adding pages AFTER disabling it:

Fatal error: Call to undefined function asset_content_is_empty() in /orko1/web/www.mywebsite.com/sites/all/modules/cck/content.module on line 837

This is very sloppy, even for a released development module, and the fact it remains up for download without adequate warning, very unprofessional, and the sign of bad development practices. I am now a slave to keeping the module enabled until I can 'hack' my way out of it, and that could take me hours and lead to more problems. Thanks to the lack of documentation on the code development.

I am somewhat new to Drupal and it's architecture, but not development. Before you 'flame' me by saying that all this stuff is free and this is use-at-your-own-risk software, yeah that's true, but you share and work on your modules for a reason other than just to share it. You want people to use them. And for people to adopt them, even if they are not in working condition, they shouldn't break other components when trying to remove them.

Looking at some of the coding practices, lack of documentation, how some of the authors respond to users, I get the sense that the majority of the module developers are not very experienced developers at all, but rather hacks or fly-by-wire coders that have no business releasing modules. I'm not perfect either, and I am also not releasing any modules I've developed for my own purposes because of that. But when I get to the point of contributing my modules, here's how I'll do it:

1) Make it CLEAR if the user should expect problems on the download page (maybe my problems here is how the Drupal module page displays information?) and keep it up to date!

2) Make things OBVIOUS! That is, not spend 35 seconds writing sentences I can only understand at the time I'm writing them to explain how to install and use the module. And, not leave out important documentation. There are some modules in the user community Drupal has allowed to be posted with ZERO documentation attached to it!

3) Provide some sort of code documentation. Something that explains the architecture of the code itself so others can contribute or at least debug problems, like mine above. I have never seen this, and the only software shops I've worked in without proper code documentation have been the ones that are now out of business.

4) Communicate effectively with the community asking for my help. Not simply saying "Give me more information about your problem", or calling them names... think about it, does that really help them? I mean, reading these posts, you have lots of newbs looking to use these modules. You think they will understand what information they need to give you for the module you wrote and didn't document? Of course not. I wouldn't do such a dis-service to the community as to ask them for something they don't understand. Instead, I'd let them know what the extra information is I need, or how to get it for me. For many of you, I can tell you don't do this on purpose, because you are so knowledgeable about Drupal and your own code. But try to step into the shoes of the user when helping them out.

So I'm sure I'll make no friends from this post, I really don't care because any one that disagrees with me on my points are not people I'd want to collaborate with any way. Like I said, I'm not perfect at all in my practices, I don't expect developers in this community to be perfect either. We all have faults and things we need to work on doing better. But some of the issues above are so basic, I am shocked that in most cases (documentation especially) are so poor in quality.

I can tell you right now, Drupal out of the box is very good, but for a very few things. The module extensions add a lot of the value to using this CMS. But with the piss poor quality of so many modules, I am ready to dump it, even though Drupal itself is solid, because extending Drupal for my purposes is far, far more time than doing it per-project in something else. That's my two cents, I hope it serves you well. I'm sorry if I bruised any egos, and the negative responses will be a clear indicator of who those people are.

⋅ Categories: Drupal 6.x

Comments

dww’s picture

dww
we/he/they
commented

Yup, there's a huge range in quality across contrib. This applies to code quality, release management, and general professionalism of the developers. No argument there. I've been on a campaign for years to improve this, and there are many others helping that campaign. Things are getting better, but there's a ton of room to grow. Some developers are incredibly careful and professional with their contributions. Some are careless, clueless, or both. Most lie somewhere in the middle. The volunteer drupal.org maintainers don't have the resources to review every contribution for quality, and the general attitude on the project is to remove barriers to contributing. That necessarily implies there's going to be low quality contributions.

For some background, check out:
http://drupal.org/node/94000
http://badcamp07.org/07/sessions/how-develop-and-maintain-your-drupal-co...
http://boston2008.drupalcon.org/session/maintain-contributions
http://drupal.org/files/maintain-release-handout.pdf

Here are a few paragraphs from that handout which summarize some of the central points I've been trying to make:

Underlying assumptions:

  • No one is forcing you to do any extra work or to do anything -- you always scratch your own itch (or the itches of people paying you).
  • No one requires that you put your code on drupal.org and share it with the world.
  • The Drupal project thrives because so many people contribute their code.

Once you upload your code, then you have some responsibilities. Putting code on drupal.org implies that you think people should use it. Therefore:

  • You have to be conscious of security vulnerabilities and be willing to fix them.
  • You should clearly state your intentions and plans as a maintainer so users can prepare.
  • You should be aware of your user-base.
  • Poorly maintained code contributed to drupal.org gives Drupal itself a bad name.

For a while we've been hashing out issues related to the technical side of this problem:
Project Quality Metrics on Drupal.org (meta document)
Project node UI redesign
drupal.org projects as Organic Groups
See also the new Advanced help module

There's been talk of community ratings for modules during the forthcoming redesign of drupal.org:
http://drupal.org/node/343078
http://groups.drupal.org/drupalorg-redesign-plan-drupal-association
http://drupal.markboultondesign.com/iteration11/modules_detail.html
http://drupal.markboultondesign.com/iteration11/modules.html
...

It's possible that will help users identify poorly maintained modules, and generally encourage maintainers to raise their standards for professionalism and release management.

In closing: There are a *lot* of ways you could help this process. As with everything in Drupal, it's "scratch your own itch". If you're itchy from the bad state of many modules, and you want to do something about it, you could:

A) Contribute documentation yourself.

B) Help educate developers about these issues in a constructive way.

C) Help the redesign of drupal.org and the project quality metrics efforts in particular.

...

Cheers,
-Derek

___________________
3281d Consulting

styro’s picture

styro commented

...in a prerelease development snapshot of a module that isn't recommended for general use yet.

I assume you just haven't got around to filing your bug report yet?

--
Anton

styro’s picture

styro commented

I found an existing CCK issue regarding this, and added a followup comment:

http://drupal.org/node/323520

Workaround: Delete the Asset fields you added to your CCK node type(s) before disabling Asset.

Asset should probably also disable/remove its fields when it gets uninstalled or disabled, but it is still at a prerelease development stage.

--
Anton

styro’s picture

styro commented

From the module code, it looks like Asset does notify CCK when it is uninstalled, but not when it is merely disabled. After all, modules generally should only delete their settings or data when uninstalled but not when disabled.

What happens if you uninstall Asset?

--
Anton

nonrate’s picture

nonrate commented

Hi Anton,

Uninstalling it does resolve the issue. The Asset module is the first one I've come across that offers un-installation, so I wasn't even aware the facility existed. If you're a maintainer of the module, you may want to add this issue to the release notes so others do not run into this problem and become confused on how to resolve it. Thanks for your help,

SD

prbass’s picture

prbass commented

Development Snapshot? Big Red Cross next to the download button?

How more obvious does it need to be that this wasn't a finished piece of work?

According to the "amateur" who kindly developed this module in D5 for Amnesty International, and the "amateurs" who began porting the module to D6.

"Please note that the current dev version is pre-alpha and is more a starting point for people who want to jump in and help coding than for actual use."

The documentation on Drupal is not perfect, but that is no excuse for not reading it.

nonrate’s picture

nonrate commented

Please re-read my post.

markus_petrux’s picture

markus_petrux commented

That's how we can help each other. If you find a bug, please report it. If you know how, please provide a patch. If already reported, please help reviewing, and so on... little by little, everyone has the oportunity to make this a better tool.

Doubt is the beginning, not the end of wisdom.

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

As dww pointed out, this varies a lot from module to module. There are something like 4 _thousand_ modules with more being added every day. Some maintainers are excellent, some just toss the module up and never care for it. It's hard for newbies to tell the difference and hopefully the redesign will help with it. The trouble is, there's only so much you can impose on people doing this for free. Yes, when you put a module up, you should be willing to take on some responsibility for it. But how much? Are you just responsible for security fixes? Or do you need to keep working to fix obscure bugs that don't affect your usage of it? How much hand holding of new users are you expected to do? There are no real rules at this point. If a module is sufficiently uncared for, it can be taken over by someone who cares about it. But you can't force the volunteer who wrote it to care for it if he or she doesn't want to.

Also, choosing Asset as an example was a real bad move. Your point, in general, is a good one, but pointing fingers at a particular module is going to get it thrown right back at you as the other responses show. If you want to have a proper discussion about this, better keep it to the general.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

nonrate’s picture

nonrate commented

Fortunately I didn't post this hoping to get an answer to the problem. I used asset as an example of one of many issues I have run into with how modules seem to be developed for the community. As I explain in my post, I use at my own risk. Problems I run into are my responsibility, not the module developers. But part of what I'm trying to say here is if you're a module developer and want to 'win' the support of the use of your module, at least release code that won't break the rest of your Drupal configuration when you decide to no longer use it. I'm sorry, no matter what anyone says, that's a complete dis-service to the Drupal community when you release something like that, whether it's under development or not. If I were the module developer, I'd pull it immediately and revert back to a known snapshot that is not so destructive, and release the bad code literally in a location where it can be picked up to be worked on by others, not displayed in the same location as a module for the community to test at-large.

I'm sure though that over time a system will eventually be developed to separate the high-risk from the low-risk. I'm surprised though at a version 7 this hasn't been implemented yet...

michelle’s picture

michelle
she/her
Primary language English
Location Wisconsin, USA
commented

"at least release code that won't break the rest of your Drupal configuration when you decide to no longer use it."

If you decide to no longer use a module, you uninstall it. That's standard practice. And you said upthread that uninstalling it fixed the problem. The fact that you weren't aware that modules needed to be uninstalled is not the fault of the asset maintainers.

There are many modules out there that are badly maintained. Asset isn't one of them. If you insist on holding that up as an example of what's wrong with Drupal's maintainers, when you yourself were at fault for the problem, then there's not really anything more to say.

Michelle

--------------------------------------
See my Drupal articles and tutorials or come check out life in the Coulee Region.

cirotix’s picture

cirotix commented

Greetings

It seems that I am one of the "amateurs" directly involved in this discussion.

Short background :

  • we have ported the asset module to D6, and we are in fact professionals with commercial interests in developing for and with Drupal. I am the co-maintainer of asset for the D6 version.
  • We have been warmly asked to release the D6 version of asset on drupal.org
  • the main maintainer of Asset has just changed. The former maintainer used to be not very active, but the new one is.
  • Until the recent change of main maintainer I hadn't a CVS access for this project.
  • This module is a dev version, intended for developpers, without any guaranty. I think that the dev in the name on the red cross are explicit.
  • In my opinion the drupal.org project section is not only a way to disseminate your work but also a collaborative development platform. "Publish early, publish often" is one of the motto of free software development. Publishing early let you have collaborative development, where other developers can submit patches

That being said I understand your point and have added this warning on the asset page :

WARNING Don't download and install the Drupal 6 version of asset unless you really know what you do. It is a release for developers of asset only. It can break all your system and can cause problems when you uninstall it. It is certainly not intended to use for production. You have been warned.

Best regards.