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