enterprise needs

Ben,
Dries and chx are really nice people when you talk with them
in person.
I agree with you that Drupal's lack of backwards
compatibility makes it
difficult for enterprise users.  One of the biggest
enterprise users
told me he plans to never upgrade.  Other enterprise users I
spoke with
about this  have reached the same conclusion.  

I've heard it said that if Drupal were forced to choose
between the
little 'guy', and corporate users, Drupal will choose the
little person
every single time.  For Dries this is a labor of love.  An
example of
what (one of) motivates him is that someone with a
terminal/serious
disease can reach out and find help through Drupal.   
Helping some big
corporation save money is not what motivates him to give so
much of his
time to Drupal.  Many people working with Drupal/civicspace
are
motivated by the idea of  empowering the
individual/"masses." 

(of course large non-profits also are enterprise users.)

I would guess there's a 25% probability that an enterprise
fork will
develop that is backwards compatible.  I do think that will
be necessary
for Drupal to become accepted in the corporate world.  At
the conference
we talked about having an enterprise user group and/or an
enterprise
mailing list.  Perhaps that can happen

Enterprise users do have a lot to offer the community in
terms of
putting modules back in and donations.

I think it's great you've written so much code.  Thank
you.  I hope you
can find a way to make Drupal fit your needs.

Ann

Hi Ann,

> Dries and chx are really nice people when you talk with
them in person.

I met Dries a couple of times. I have a lot of respect for
him.

> I agree with you that Drupal's lack of backwards
compatibility makes it
> difficult for enterprise users.  One of the biggest
enterprise users
> told me he plans to never upgrade.  Other enterprise
users I spoke with
> about this  have reached the same conclusion.

I think I have a much clearer understanding of Drupal's
nature and
developer side now. A lot of the feedback was constructive
and if
anything, has helped me make the big decision of whether
choosing
Drupal, or continuing to use it as our corporate CMS is the
right
decision.

Before developing with Drupal, I didn't care much about the
development processes behind the scenes. I just downloaded
it,
installed it and used it. Now that I've invested a lot of
time into
writing drupal code, and had at some exposure to the
developer culture
behind it, I actually have opinion about some things.

My boss made a great observation about Drupal. It's too
hard to use,
too "techie". That's pretty true on the flip
side too. Regardless of
my skills, I find it difficult to make positive
contributions to core.

I can "fix bugs", but why when the original
authors are the most
qualified to fix those bugs?

I can "find bugs", but I wonder why don't we
have better quality
control in the first place. Isn't introducing _more_ bugs
with every
new feature a clear indication our processes need to be
examined?

I can contribute modules. I have a slick authenticated web
service
module but have been waiting on a CVS account for a couple
of weeks. I
can host and source control my own module, but there's no
way to add
it to contributions on the site. Frustrating.

Take it as a rant or criticism, but being less techie,
isn't
neccessarily a bad thing. In the end, I just want to see
Drupal do
well. I want to contribute, and I want to do it without
having to
spend a lot of time stroking egos and doing grunt work.

Thanks.
Ben.

Benson Wong wrote:

>Hi Ann,
>
>  
>
>>Dries and chx are really nice people when you talk
with them in person.
>>    
>>
>
>I met Dries a couple of times. I have a lot of respect
for him.
>
>  
>
>>I agree with you that Drupal's lack of backwards
compatibility makes it
>>difficult for enterprise users.  One of the biggest
enterprise users
>>told me he plans to never upgrade.  Other enterprise
users I spoke with
>>about this  have reached the same conclusion.
>>    
>>
>
>I think I have a much clearer understanding of Drupal's
nature and
>developer side now. A lot of the feedback was
constructive and if
>anything, has helped me make the big decision of whether
choosing
>Drupal, or continuing to use it as our corporate CMS is
the right
>decision.
>
>Before developing with Drupal, I didn't care much about
the
>development processes behind the scenes. I just
downloaded it,
>installed it and used it. Now that I've invested a lot
of time into
>writing drupal code, and had at some exposure to the
developer culture
>behind it, I actually have opinion about some things.
>
>My boss made a great observation about Drupal. It's too
hard to use,
>too "techie".
>

I prefer the term "powerful".

> That's pretty true on the flip side too. Regardless of
>my skills, I find it difficult to make positive
contributions to core.
>  
>

Most people don't start by rewriting large parts of core.

>I can "fix bugs", but why when the original
authors are the most
>qualified to fix those bugs?
>  
>

Cause they might not have the time, or even care about bugs
in a part of 
the code that they don't feel is that important to them.

>I can "find bugs", but I wonder why don't
we have better quality
>control in the first place. Isn't introducing _more_
bugs with every
>new feature a clear indication our processes need to be
examined?
>  
>

Uhhh. One thing about Open Source development is that there
are usually 
not many processes involved...

Over the years, we actually have resolved to implement some
processes. 
Feel free to suggest improvements, but for continued good
working 
relationship I suggest you scratch "backwards
compatibility", 
"responsibility",  and related items from your
vocabulary.

>I can contribute modules. I have a slick authenticated
web service
>module but have been waiting on a CVS account for a
couple of weeks. I
>  
>

Happens.

>can host and source control my own module, but there's
no way to add
>it to contributions on the site. Frustrating.
>  
>

IIRC, I approved your account.

>Take it as a rant or criticism, but being less techie,
isn't
>neccessarily a bad thing.
>

Why should it? But since we  - the techies - need to develop
Drupal we 
are usually very reluctant to accept suggestions from
outsiders.

> In the end, I just want to see Drupal do
>well. I want to contribute, and I want to do it without
having to
>spend a lot of time stroking egos and doing grunt work.
>  
>

Sorry to say so, but no aim is achieved without effort. If
you don't 
feel like doing grunt work once in a while, the processes
that need a 
review are yours not ours.

Cheers,
    Gerhard

On 25 Feb 2006, at 02:08, Benson Wong wrote:
> I think I have a much clearer understanding of
Drupal's nature and
> developer side now. A lot of the feedback was
constructive and if
> anything, has helped me make the big decision of
whether choosing
> Drupal, or continuing to use it as our corporate CMS is
the right
> decision.
>
> Before developing with Drupal, I didn't care much
about the
> development processes behind the scenes. I just
downloaded it,
> installed it and used it. Now that I've invested a lot
of time into
> writing drupal code, and had at some exposure to the
developer culture
> behind it, I actually have opinion about some things.

Drupal's development process resembles that of most Open
Source  
projects.  I don't think the development process is broken
-- what's  
not to say it can't be improved.

Where we often differ is in our culture of backward
compatibility.    
 From day one, I decided not to care about backward
compatibility and  
it has been one of our core values ever since.  (However, we
only  
break your code, not your data.)  Either you like that, or
you  
don't.  The problem is exactly that.  It's very much a
matter of  
opinion as there are both advantages and disadvantages to
either  
philosophy.  For example, if we were to support backward  
compatibility, we'd be in the exact opposite situation. 
People would  
be vocal about the fact that we drag 100k of deprecated code
around,  
that it adds a burden that slows down the release cycle or  
innovation, that their sites could be much, much faster if
only we  
got rid of the legacy code, etc.

The real question is: why is upgrading _that_ important?

The Drupal 4.6 release has been out there for almost one
year now,  
and is likely going to be maintained for at least another
one or two  
years.  And depending on the needs, much longer than that. 
(In the  
Linux kernel world, the 2.0 release series are still being
maintained  
despite the fact that the original 2.0.0 kernel was released
in  
1996!)  If you want a stable branch, you can use a stable
branch.

--
Dries Buytaert  ::  http://www.buytaert.net/

On Sun, 26 Feb 2006 09:28:32 +0100  Dries Buytaert wrote:

> The real question is: why is upgrading _that_
important?

I basically agree with everything you just said.  I'd like
to offer
one possible answer to this real question you raised:

  "because every module maintainer has a different
opinion about how
  to manage fixes and improvements in the different versions
of their
  modules, and drupal can't do much of anything without at
least
  *some* modules enabled."

It seems that if you want anything improved about your 4.6
site, you
either have to manually maintain a forked copy of the 4.6
module code
base (which is what i'm doing, while trying to submit as
many patches
back to the issue queues as possible), or you have to
upgrade to 4.7.

A few anecdotes to illustrate the point from my recent
history of
interacting with different module maintainers:

1) A trivial patch I submitted to the project.module to fix
a
permission problem in 4.6 wasn't going to be committed
(without some
prodding) because "4.6 is frozen", even though
the code was actually
broken (one of the access control permissions didn't work
at all if
you tried to enable it) and a 1-line change got it working.

2) A very handy feature in simple_access.module was
discussed at great
length as a 4.6 improvement, but finally the maintainer just
committed
it to the 4.7 version of simple_access and closed the issue.
 To
further complicate this, the fix was done in the same commit
as
porting the entire module to the 4.7 forms API, so it's now
going to
be a lot of effort to extract this feature (which many
people using
4.6 wish they had) from this monolithic commit and get it
working in
4.6 (it doesn't appear to require 4.7 forms for any real
reason).
Even if I did the work, it's unclear if the maintainer will
actually
apply it to 4.6.

3) The maintainer of signup.module wants to completely
re-write and
re-organize the entire 4.6 signup codebase, to make it more
modular
and off-load more of the forms-related stuff it's doing
into modules
it should depend on (partially in response to the avalanche
of patches
i've submitted that provide new functionality I needed). 
So, folks
trying to use the "stable" 4.6 signup might find
that one day, when
they download the "4.6 signup" (since there's
no versioning of
modules, something that makes doing your own revision
control with
vendor branches more of a pain), all of a sudden the entire
look and
functionality of the module has completely changed from the
last 4.6
site they setup, it now depends on 3 other modules, etc.

So, 3 very handy modules have 3 completely different
philosophies on
what to do with their "stable" version.  Project
didn't even want to
fix a known bug with a trivial solution, since (at first)
that was
considered too much of a change to a now-frozen stable
release.
simple_access seems willing to do bug fixes to 4.6, but
anything new
goes into 4.7.  Signup seems willing to completely change
everything,
right in the middle of a "stable" version.


I'm still not sure what I think about the fact that
there's no
consistency across modules in this respect.  Of course,
it's great
that ultimately, everything is open source, and I can (and
do) just
get my own 4.6 site working exactly how I want, with some
combination
of stock modules, custom modifications, and occasionally,
updates to
the modules from the real maintainers when they fix or add
something I
care about.  

However, that's not an ideal model, since it makes the cost
of using
drupal pretty high.  I happen to have been writing code and
using CVS
for well over a decade before I ever heard of drupal, so
even though I
had never written a line of php a few months ago, I could
add a bunch
of functionality I needed and fix a lot of bugs I found. 
But most
people trying to use drupal to setup a website aren't going
to have
those skills and that experience to draw from (nor many
thousands of
dollars to hire someone who does).  If one of the motivating
philosophies behind drupal is "down with The Man,
let's help the
underdog" (which I totally support), that doesn't
quite jive with
"only if the underdog is already a computer
programmer, or has a $20K
budget for their website".

It also complicates the question "why bother
upgrading?".  Depending
on what modules you need, you're often faced with the
difficult (and
somewhat evil) choice of a) redo a lot of work someone
already did to
the 4.7 version or b) upgrade your entire site to 4.7.


This is *not* an argument for crippling drupal by tying its
hands to
backwards compatibility.  We've gone down that road for the
university
research project I work on for my day job, and it's a
*major* waste of
developer time, source of bloat, and maintenance costs. 
I'm just
raising the issue that while the core has a clear philosophy
and
(mostly) clear process, the modules are all over the map,
and
precisely because of drupal's (correct) emphasis on
modularity, core
drupal *on its own* isn't very useful for doing much.

I'm still too new around here to have any profound insights
on what to
do about all this, so unfortunately I don't (yet) have a
concrete
suggestion to share.  Given the distributed ownership and
maintenance
of the contrib modules, I don't think it'd be possible (or
wise) to
enforce any kind of uniformity.  I just wanted to offer my
perspective
as a new drupal user and developer, trying to keep a live
site happy
and stable in 4.6, but still getting new functionality or
bug fixes I
need to solve real problems I'm facing.  I hope this is
helpful input
into the discussion...

Thanks,
-Derek

Dries Buytaert wrote:

> The real question is: why is upgrading _that_
important?


Good question. I ran a 3.0 install untill after 4.4 was
available. It 
was probably very insecure, but nobody knew that. :p

> The Drupal 4.6 release has been out there for almost
one year now,  
> and is likely going to be maintained for at least
another one or two  
> years.  And depending on the needs, much longer than
that.  (In the


That would be a change in policy. Our current policy is to
support the 
current stable release and the one before it. That would
mean that 4.6 
would be not supported after the release of the version
after 4.7.

Cheers,
    Gerhard

> That would be a change in policy. Our current policy is
to support the 
> current stable release and the one before it. That
would mean that 4.6 
> would be not supported after the release of the version
after 4.7.

thats a result of limited resources for the security team. i
suspect that 
4.6 will live on for years because either someone funds the
drupal.org 
security team or some volunteers to maintain the branch.

> Where we often differ is in our culture of backward
compatibility.
>  From day one, I decided not to care about backward
compatibility and
> it has been one of our core values ever since. 
(However, we only
> break your code, not your data.)  Either you like that,
or you
> don't.

Just to be clear, we did not do this for no reason.

The reason for not maintaining backward compatibility is
stop this
as a  hinderance for innovation.

As painful as upgrades may be, the disregard for
compatibility in
core is one  of the main reasons Drupal continues to develop
new
features, refactor existing ones, and be cutting edge, yet
nimble

Op zondag 26 februari 2006 15:59, schreef Moshe Weitzman:
> thats a result of limited resources for the security
team. i suspect that
> 4.6 will live on for years because either someone funds
the drupal.org
> security team or some volunteers to maintain the
branch.

I actually suspect, taken in consideration the large changes
in API betwen 6 
and 7, that 4.6 will live on for a long while. Which is
good, IMO.
And its OSS: nothing stops people from grouping around some
drupalfoursix.org. 
It does not need to be 'official' in order to work 

-- 
| Bčr Kessels | webschuur.com | website development |
| Jabber & Google Talk: berjabber.webschuur.com
| http://bler.webschuur.com | http://www.webschuur.com
|

Comments for Dries:

> From day one, I decided not to care about backward
compatibility and
> it has been one of our core values ever since. 
(However, we only
> break your code, not your data.)  Either you like that,
or you
> don't.

Straight from the horse's mouth. 
Thanks.

For Derek:
First off, excellent and very helpful input.

> However, that's not an ideal model, since it makes the
cost of using
> drupal pretty high.  ... most
> people trying to use drupal to setup a website aren't
going to have
> those skills and that experience to draw from (nor many
thousands of
> dollars to hire someone who does).  If one of the
motivating
> philosophies behind drupal is "down with The Man,
let's help the
> underdog" (which I totally support), that
doesn't quite jive with
> "only if the underdog is already a computer
programmer, or has a $20K
> budget for their website".

This hits the nail directly on the head. A small addition,
perhaps
providing the means, rather than enforcing the will is a
good
approach. I dream of Drupal switching from cvs to svn.

Better access methods (https), finer grain access control,
access
control lists, etc. We can have a guideline for a contrib
module's svn
directory structure like:

/my_contrib
  head
  tags
   4.5
   4.6.4
   4.6.5
   4.7-BETA4
   ...

Contributors can choose if they want to use it or not.

It's very little work for a contributor to checkout the
4.6.5 version
of their module, fix some bugs, and commit the changes just
for that
version of drupal. Much easier with SVN than CVS (I think).

Another plus is that people who depend on their code can
just export
the correct tag. A lot easier too...

ie: svn co https://svn.drupal.org/respositories/cont
ributions/my_module/tags/4.6.5

Ben