[drupal-devel] DrupalForge?

[Dan Robinson]

>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...
>  
>
There may be too much - but it is slick nonetheless.  Remember a lot of 
people "buy" based on initial impressions.  They may get disapointed 
later - but unless the overall experience is terrible - they will just 
stay connected to what they've got.

>  
>
>>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.
>  
>
yes - and "pretty" pictures.

>  
>
>>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.
>  
>
why not just have a full db and just use a cron job to keep blowing it away?

>  
>
>>3) Their look is polished and professional.
>>    
>>
>
>I like to think drupal.org is too.
>  
>
well - yes and no (IMHO).  While in reality drupal.org is well designed 
from a usability point of view - the graphics peg it as a "project" as 
opposed to a "product" (IMHO).

>  
>
>>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...
>  
>
well this is true to an extent.  You don't want growth for growths sake 
necessarily, but remember there is probably a direct relationship 
between the number of users and the number of developers.  It would be 
cool if we could double the number of developers working on Drupal 
without lowering the quality.

>  
>
>> 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.
>  
>
My point was that just because you have great technology doesn't mean 
you "win" in the marketplace.  Drupal deserves more recognition because 
it is a kick-ass system (and more importantly - community).

>  
>
>>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.
>  
>
well I've only used it for software tracking and my experience with it 
(compared to only slightly more experience with bugzilla) is that 
feature for feature bugzilla wins hands down.

>  
>
>>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. ;^)
>  
>
yes - it would be great if we had a competitive analysis - point by 
point - the other thing I saw over at MS (hmmm....) was that I couldn't 
find their CVS :).

>  
>
>>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.
>
>Cheers,
>	Gerhard
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://drupal3.drupal.org/pipermail/development/attachments/20050424/bbbec5c0/attachment.htm