I have been working with Drupal for a while now and first of all I should say this is one of the best CMS around with it's robust community base and following. Over the time Drupal has matured enough to stand as a leader in the Open Source CMS. However, after a careful study of Drupal as a system (sorry I am a information system analyst by trade). I personally think Drupal has failed in some areas when it comes to managing the project in itself.
I know you will jump up and say "what is he talking about?".
I did a bit of case study for Drupal, first I would highlight it's positive points (I am referring to the social networking aspect of it, in terms of a layman)
- Very large community base
- Well structured documentation and API.
- Maturity in terms of time being in CMS market.
However some of the down-falls, which can be easily rectified or sorted.
- Poorly managed projects.
- Very high resource intensive queries,
- Cluttered or unorganized information.
You may or may not agree with me on this, Drupal seems to very unorganized when it comes in terms of project management. Just a look at the issue queues reflect the fact. I agree Drupal is open source and hence "free" and people who contribute do it on voluntary basis.
However, that's no excuse to quality management, if we are to stand in the world of web 2.0, quality has no compromise.
Over the years we have seen major social networking sites merge and data is being not withheld in one place but shared over various channels to the end user. My argument is why does not Drupal harness the power of web 2.0 and make a projects into collaborations.
Rather than having 2-4 same modules "Projects" maintained by more than 5-6 highly qualified and good programmers, why not create a single project and distribute it amongst those programmer or coders. For example just click on the tag "Content" in module section you will find more than 400+ modules, and from my research 50% of those modules do the same work with a certain functional additions or add ons to the previous one.
It's not only confusing for the end user but difficult to merge such a large project base into a single website or a web project. I personally think it's waste of time for people developing those projects, because a lot of projects are abandoned and people who are already using them are left with no option but to either migrate to some other module or play wait game. Some projects have not even come out of dev version for years altogether.
Also a lot of projects try to enumerate the functionality of other social networking giants, Kudoes to them for trying it and sharing with community.
I will take the example of the module Facebook Style Micro-blogging, which is trying to enumerate the functionality of Facebook Wall, but honestly has it even come close to that. It does not have any easy functionality merge with “user relations”. I am not trying to criticise the developer of the module. However, my aim is that it does not make any sense to have so many projects doing the same thing. And having to have so many modules doing nearly same thing but you have install 4-6 modules to get one basic functionality.
I do not have massive knowledge in programming as I am a business management student. To my understanding merging modules together would also lower the resource dependence of the API itself.
Say for example Drupal creates a project under the name “Relationship API”, and assigns programmer to work on it and gives every programmer a simple talk to accomplish, rather than have 3-4 module doing the same thing.
As in one programmer is responsible for the UI, another for the API, another for integration of other modules and someone for UI documentation. All this can be achieved with power of data and knowledge sharing.
This could/will enhance the position of Drupal as a leader in CMS market and create a stringent quality control. Not only does data collaborations enhance maturity but richness of the product itself.
Drupal is no more a test or prototype, it's a product which Drupal Community is providing in the market of open source. So we should provide our consumers with quality products and better quality.
Anyway this is just a case study on my end, I maybe wrong comments and suggestions are welcome.
Comments
What you're talking about is
What you're talking about is not a technical problem but a social problem.
There is a lot of collaboration between modules between projects, in the cases where there are not, the project maintainers have usually communicated and decided that collaboration is impossible due to personal conflicts, differences in visions and needs, ego, etc.
In an ideal world everyone would collaborate peacefully, but that is not so. You're asking for d.o administrators to make a top down decision and force people to collaborate. That sort of heavy-handedness would be really horrible, I don't think anyone who contributes to the community for free would like that.
Yes, the contrib community is sort of inefficient in that there's a lot of duplicate work, but the competitive model we have now should win over any 'command economy' system in the long run.
.
"Drupal" is a computer program, and it's not an AI, so it's not going to create projects and assign manpower. And how, exactly, do you propose assigning volunteers to work on something, anyway?
Could things be organized better? Sure. There's ongoing work to redesign the Drupal* sites to make it easier to find information. And that will help some with module duplication. But there are other issues that just organizing data won't fix and it's a problem that isn't going away.
This really isn't the proper group for this post since its only relation to Drupal's social networking modules is as examples. Not sure there's much point in moving it, though. No matter where it's put, the response will be that you need to learn more about how this community works and what you're proposing just isn't going to happen.
Michelle
To @Flying Drupalist Yes, the
To @Flying Drupalist
I agree to that fact that competition creates better products and system, however, as you yourself have pointed out that
This is downfall of any project in the long run, it's not about command economy but about collaborative economy. Any programmer who is trying to give a product to the community should forgo his/her ego. Any contributer to Drupal should work and enforce the vision of Drupal not his or her own. Providing "free" service does not make them less responsible to the community, in my opinion we are more responsible to community than paid versions. Cause over the years we have created this phenomena that Open Source is the best. This in itself has created a large responsibility for contributer as community depends on such collaborations.
To @Michelle
I never deviated from the fact that Drupal is a computer programme, not AI, however, HI (human intelligence) is running it. As far as assigning volunteers to such way is actually very easy. Drupal already has CVS application system, instead of creating multiple projects or modules, why not as in my example discussion groups, where people join hands to find issues, do brain-storming, find ways, as old age saying goings Where there is a will there is a way on this point I will agree what @Flying Drupalist has said
.
In the end competition system is great but who are we competing with; programmers in our own community or the CMS market, that's the question. Do we want to create a better UI for end users or not. Divided anything falls and only creates issues, fallouts and confusion. But when a team stands up and takes a project in hand and multiple brains are stormed better ideas turn up.
You bring up some great
You bring up some great points.
It's important to keep in mind that a lot of what is mentioned is not drupal specific by any means.
It's also important to have some level of programmer mentality to understand why and how things often operate in terms of development.
While logically it makes sense to combine modules that have similar functionality or operate under the same umbrella, this doesn't mean it's the best way. Is it very annoying and hard to keep up when you need to install 3 modules to do one task? Of course - but, modularity allows for extra possibilities. For example, instead of hard-coding a huge module that does 20 things, it's better to split it up into 20 modules that do one piece of the puzzle. That way people can pick and choose what they do/don't want and the possibilities of how things can be extended. The problem isn't in actually installing the modules, the problem is knowing which to install and how/where to find them. I think rather than combining everything, it would help to group and relate more similar/extensions together. For example if one module extends or builds off another's API, it should show up on the main project page showing that it's related.
I do think however there is (in all opensource circles) a problem with reinventing the wheel. It's very common that programmers like to 'do it themselves' rather than use someone else's and it inevitably leaves to reinventing the same thing multiple times.
You pinpoint exactly the
You pinpoint exactly the problems I always have when setting up a drupal-site.
The list of modules is overwhelming but if you have a close look at it:
* some are only available as "dev"
* some are deprecated
* some are not actively maintained
and in the end you come up with empty hands.
I think the core-problem is, that it is more easy to create a new module than to cooperate with other developers to enrich an existing module.
@cerup "programmes like to do it themselves". Oh yes, you're so right. But I think we all should boost "community plumbing" a little bit more.
Nevertheless I like drupal very much
Best regards
Stefan
@cerup For example if one
@cerup
That's exactly what I mean by collaboration, what I mean is that there should be some sort of specific guidelines, which do not duplicate the functions but extend the modular functions. Very good example is Friendlist module, it's programmer when pages all over the drupal.org about how good his approach is, but where does it stand now.. no clue..
This kind of approach is confusing for the end users. Any "program" I think is created keeping the interests of an end user in mind. If everyone was very knowledgeable in programming interface why would they need to turn to any module. They will do it themselves. What I mean is we have come up with a solution where an API is created and then other modules grow on it. example will be:
An API for user relationships
then modules for :
Node access based on it, comment access, Actions, UI, etc... basically it will grow in a unilateral direction not be haphazard in nature.
@svegel
That's the problem and there is no control system to stop it from happening, many people just develop modules to boost there ego, because the maintainer of ABC module didn't accept a patch or suggestion.
People Drupal is open-source free to modify and contribute, that's what should be in mind and there should be a system to integrate community development into existing modules. eg, I Have found a lot of additional functions just by checking issue queues of modules, but they have not been committed to the CVS yet.
In the end I would say, collaboration is the key to solve this riddle.
Yeah, great points. As said
Yeah, great points.
As said before though, this isn't at all unique to drupal. This is a global problems in all opensource communities with large followings.
You'll never be able to force people to extend another module; so I don't think that should be enforced as it would actually hinder the development of modules. What I do think that can happen is a smarter UI for linking what is currently out there. Having people easily see the relationships between modules will give them a better idea of what is/isn't needed. Encouraging people to do something is better than forcing them to.