enterprise needs

On Mon, 2006-02-27 at 20:11 -0800, Nedjo Rogers wrote:
<snip>
> But this small distinction gets fairly near the core of
the issues we're 
> discussing.  The situation is that a lot of (paid,
economically significant) 
> work depends on volunteer contributions--from Dries on
down to module 
> maintainers.
> 
> The thing about volunteers is that you can't really
require them to do work. 
> They'll contribute largely what they want to, what
interests and motivates 
> them.  Generally speaking, when there's limited time
available, doing 
> maintenance on old releases is often going to rate
relatively low when 
> measured up against, e.g., getting an innovative new
version out.
> 
> So maybe the question really becomes: how do we enable
those who depend on 
> old releases to contribute to maintaining them?

<snip>

If your economic welfare depends on drupal, set up a
cvs/svn/bzr
repository with drupal 4.6 as a vendor branch, make the
changes and bug
fixes you need. You should be willing to contribute your
upgrades back
to the community and hope they get accepted back into the
main tree. 

The fact is your business needs are probably immediate, the
development
communities needs are probably less immediate than your
friday deadline.
If you want to build your business on an open source
foundation, be
prepared to do some work.

You can't guarantee that community process will conform to
your
businesses needs, or that if they do conform for a period,
that they
will stay that way.

.darrel.

Op dinsdag 28 februari 2006 18:11, schreef Darrel O'Pry:
> If your economic welfare depends on drupal, set up a
cvs/svn/bzr
> repository with drupal 4.6 as a vendor branch, make the
changes and bug
> fixes you need. You should be willing to contribute
your upgrades back
> to the community and hope they get accepted back into
the main tree.
>
> The fact is your business needs are probably immediate,
the development
> communities needs are probably less immediate than your
friday deadline.
> If you want to build your business on an open source
foundation, be
> prepared to do some work.
>
> You can't guarantee that community process will
conform to your
> businesses needs, or that if they do conform for a
period, that they
> will stay that way.

This says it all!

Nail on the head Darrel.

I would like to add, register your project (bzr svn or
whatever). That way 
ohters might pick up your fridays-deadline-hacks and improve
them, or build 
on top of them. And off course submit them as patches.

Bèr
-- 
 PGP berwebschuur.com
  http://www.webschuur.com/sites/webschuur.com
/files/ber_webschuur.asc
 PGP berkesselsgmx.net
  http://www.webschuur.com/sites/webschuur.com/files
/ber_gmx.asc


Gebruik geen CVS, tenzij je zeker van je zaak bent:
 http://help.sympal.nl/gebruik_geen_cvs_te
nzij_je_zeker_van_je_zaak_bent

On Tue, 28 Feb 2006 12:11:19 -0500  "Darrel
O'Pry" wrote:

> If your economic welfare depends on drupal, set up a
cvs/svn/bzr
> repository with drupal 4.6 as a vendor branch, make the
changes and
> bug fixes you need.

for the record:

a) i'm not an enterprise, just an individual user doing all
this
   drupal work on my own time, for my own private site for a
brazilian
   percussion ensemble i direct. ;) i'd like to start using
drupal for
   my day job (academic staff  the uw-madison comp sci
department),
   but that's another story...

b) setting up a cvs repository and importing drupal 4.6 as a
vendor
   branch is exactly what i did.  

   (side note: the fact that contrib modules don't have
real version
   numbers makes using vendor branches more of a pain, since
you have
   to tag based on the date you imported, not some
reasonable version
   number of a given contrib module).


> You should be willing to contribute your upgrades back
to the
> community and hope they get accepted back into the main
tree.

that's what i've been trying to do.  my point is that
it's not so easy
to do this (especially given the divergent interests and
policies of
each contrib module maintainer), and it's time consuming
and (so far)
somewhat unrewarding work.


> If you want to build your business on an open source
foundation, be
> prepared to do some work.

i agree (even though i'm not a buisness).  i already have
done lots of
work.  since it's open source, and i believe in open source
in
general, i'm spending a bunch of *additional* effort trying
to get my
fixes and improvements back into the main version so
everyone can
benefit from them.  i'm just trying to make suggestions
about what we
as a community can do to make that process easier.  i don't
think that
just because people *can* fork any module and maintain their
own
version of it means that should be the first suggestion. 


> You can't guarantee that community process will
conform to your
> businesses needs, or that if they do conform for a
period, that they
> will stay that way.

i'm not motivated by having drupal conform to
"buisness needs" per se,
i'm just talking about basic usefulness to the world.

my point boils down to this:

  because drupal is so modular, every drupal site depends on
at least
  a few contrib modules.  there's a clear social policy and
process
  for changes to core that people can at least understand
and live
  with.  there's no such policy for contrib modules.  since
sites
  depend on both core and contrib, they're usually stuck in
the middle
  of inconsistencies regarding when/where things get fixed
or
  improved.

i think it'd be in drupal's overall interests to try to
close this gap
in some way.  i've been trying to come up with ideas and
suggestions,
but it's a hard problem, and i still feel very much like an
outsider
in this community.  i'm not slaming anyone, or complaining,
i'm just
trying to help make improvements based on my own experience
interacting with drupal so far.

thanks,
-derek