[drupal-devel] DrupalForge?

Gerhard Killesreiter killesreiter at physik.uni-freiburg.de
Sun Apr 24 19:23:00 UTC 2005

On Sun, 24 Apr 2005, Dan Robinson wrote:

> > Personally, I prefer to devote my time improving the project module.
> > The fact that we eat our own food, motivates us to improve, refactor
> > and tune Drupal to become a better platform.
> Well I find this a fascinating conversation.  I've come across Mambo now
> in a couple of situations and don't really know much about it.

Same here. I have just last week had a look at its admin interface.
While it is very slick, I think there is a bit too much on it...

> However
> my observations are:
> 1) Their website is geared heavily towards a less-technical community.
> They are focussed on end-users, web designers and web masters.

Lots of marketing blurb, I agree.

> 2) Their admin panel gives great demo.

Maybe we could have a pseudo-demo. By pseudo-demo I mean that we could
have a html dump of an admin interface without any working forms. This
would save us from needing another database etc. but would people allow
to have a look behind the scenes. People who'd like to have a real demo
site could go to opensourcecms or what was it called. In any case we
should have a prominent link to oscms.

> 3) Their look is polished and professional.

I like to think drupal.org is too.

> While their product may be technically inferior, their marketing is
> better (assuming you want more users).

I think that most developers wouldn't mind more users, but would prefer
not to have just any user...

>  Remember - betamax got beat by vhs.

I don't see that this is about beating someone. There are lots of CMSes
in the world and I rather see this is good than as bad.

> I completely understand the "eat your own dogfood approach".  I also
> understand the "focus, focus, focus" approach as well as the "do what
> you do best" approach.   I think that the project module is a great
> example.  My experience with the project module (for bug/feature
> tracking) is in comparison with bugzilla.  Bugzilla looks and feels
> really terrible - however it really gets the job done.  What is the
> relative importance in having a great drupal project module to other
> important features?  How is this communicated within the community?

The project.module isn't bad at doing what it was designed for. Quite
the contrary. Buit since Drupal grows at a rather steep rate we need to
improve it.

> What is more of a motivation - saying that we're using something of
> inferior quality and hoping that the pain of using it will encourage
> developers to meet the challenge?

As I outlined before the problem is that project.module will not get
much attention because of its focus on Drupal and drupal.org. Free
software development is about scratching one's own itches and I for
example can use project.module just fine on drupal.org but cannot use it
anywhere else due to design limitations.  Thus no itch and no code.

> or using something that does the job well and being embarrased that
> it isn't native drupal?  (one thing I noticed is that the forum
> discussion boards at MamboServer are using a 3rd party commercial
> product :) ).

Something I'll happily point out to any potential clients. Thanks. ;^)

> Anyway - interesting discussion.

According to the "talk is silver, code is gold" mantra we should get
some code in the project module just now...

Things to consider:

- Would it make sense to use actions/workflow.module for it?
- Why does it need to have its own comment stuff?
  Probably in order to have the extended form that we use.
  This could be a reason to apply the commentapi patch to Drupal and go
  from there to removing the extra comment handling in project module.
- Remove hardcoded status codes.
- Introduce better mailed issues. Issues should be mailed similar to
  how mailman mails digests.


More information about the drupal-devel mailing list