[development] RFC: drupal as a moving target

[Steven Peck]

On Mon, Apr 28, 2008 at 9:30 AM, Ivan Sergio Borgonovo
<mail at webthatworks.it> wrote:

>
>  Here discussion spend a lot of time on the Docs problem
>
> http://drupal.org/node/132496
>  but the more the project is mature the less simple modules you'll
>  find cos the API is better the more you'll see thousands lines
>  modules developed.
>  --
>  Ivan Sergio Borgonovo
>  http://www.webthatworks.it
>
>
Actually that thread spent a lot of time complaining with multiple
people claiming that they were owed and refusing to participate.  Also
it was pretty much a non-issue.  It is also a fundamental
mis-understanding of Drupal historically and of open source in
general.

The code has been consistently self documented and there have been
major drives to improve and backfill gaps in the last two years.  The
database schema is now fully documented with a mechanism to maintain
this documentation going forward.

Change is driven by the active development community.  It is the only
way it happens.  This is not new.  This is how it works.  In order to
'slow' everyone down you'd have to stop everyone contributing.  People
contribute for a variety of reasons.
1.  It's an interesting puzzle.
2.  The present way bothers them and there is a better mouse trap
3.  The present way needs improvement for real world solutions
4.  It serves someone's needs
5.  Build karma
6.  Learn something neat
7.  It feels good to participate in a community and help people

Note, nowhere is 'sell this product'.  There are other open source
products with a commercial model.  Many of them are successful, some
started out with this commercial model in mind.  These commercial
types of open source products also serve to confuse people.  Drupal is
Open Source.  It is also over seven years old.  Over because it was
released in 2001 as version 1 but had a community around it before
then.

Historically, you don't sell Drupal per se.  You sell your ability to
solve your (customers) needs and that happens that the best vehicle is
Drupal.

Historically the list and forums are littered with posts just like
your email.  People think it's time to 'slow down' for 'some various
reasons of their own' without understanding the actual volume and
workload involved because it's largely invisible to them.

To clarify some things, I wrote many of those 'policies'.  I wrote
them because the question kept coming up and I was tired of answering
it.  I didn't determine policy, I solicited feedback from many people
on early versions of the document (years ago) and clarified what the
community custom was among the developers.  A lot of this is what was
actually happening at the time and what was a 'reasonable' expectation
would be.  People were complaining that "they didn't know".  So, now
it is documented.  People do not have the excuse that "they didn't
know".  It was determined that this was reasonable based on the burden
on various volunteers willingness to do this.

I frankly don't see what has changed except that it's time for someone
to try and slow the project down to conform to their needs again.
Historical hallmarks of Drupal
1.  Does not have an expectation of code backwards compatibility, just
data preservation.
2.  Rapid release (note, this has actually slowed down over the years
which you can validate through the Change logs) which is a more
natural method to achieve this goal then some random artificial one.
3.  This very discussion gets raised every 6 - 9 months
4.  Things go on as before.

With each release Drupal will always be 'more mature'.  There will
hopefully not be a point in the next few years were it won't be that
way.  But we cannot predict which web technologies will be on the rise
in the next year.  Which technologies, capabilities will be coming to
the fore that we want to provide core api's for?  Will it be the next
taxonomy, javascript, open id?

> Giving a more guided pressure on contrib may end up in keeping up the
> good continuous stream of quality modules that require more time to
> be ported than the 300 lines stuff and gaining market share as well.

Let's manage change to make a few people have significantly more work
(and burn them out and overwhelm them more) to 'control' contrib is
not a solution.  In my opinion, the vast overwhelming benefits that
mostly free range contrib is sign of a very healthy eco-system.  Yes,
it can be confusing and overwhelming and that is unfortunate but it is
also a wealth of diverse ideas and solutions and many of them survive
and build little mini-communities around them that is also healthy.

---------------
Now, this next bit is my little personal philosophy.
---------------

Drupal is _not_ a company.  It is not a business. It is a community
that produces code.

It was not started as a business and I was not attracted to it because
it was a business.  It does have businesses that surround and support
it but they evolved to leverage and take advantage of it.  Drupal did
not arise out of a desire to make a company money.  As an amorphous
entity it is not about gaining market share.  It is a community that
is passionate about building relevant tools that help them solve their
needs on the Internet.  It is about improving that code and experience
for themselves and each other.  Being able to solve your needs and
leverage others skills who have solved their needs in a way that
unexpectedly benefits you.

So the only way to know and understand Drupal is to be involved.  Be
involved in code contributions, reviews, documentation, support help.
This gets you familiar with the code, the current methodologies and
best practices that have evolved.  The trends and directions.  It gets
you a seat at the community cafeteria tables.  You can change tables,
focus on something else, pull tables together.  But you have to be
involved to understand things.  this is not about being a 'big shop',
this is not about being a business.

If Drupal becomes about being a 'business', I will take my chair and go home.

I don't do this to support your needs, I do this to support mine.
That I do it with the community in a way that others also benefit is
good because I learn from other people sharing solutions to their
needs and that can bring even more people and diverse talents and
skills in.  But ultimately, we all do it because it solves our own
needs.

I don't care about _your_ immense costs and you do not give me any
reason to care either.  That is another non-argument raised before yet
we continue to speed adoption.  Open Source does _not_ cost less, it
costs different.  If you do not prepare your client/customer/company
for that reality, then you are doing your client/customer/company a
dis-service.  This is also _not_ any different then most/many
commercial products that you pay licensing costs for.

Your costs aren't giving me money to pay my bills and frankly, I have
managed to upgrade my 10 sites and support several friends on theirs
fairly consistently by myself for several years now.  They aren't
fancy but they are mine.  They solve my needs.  And they solve my
friends needs.

If a business looking to use Drupal can't live with that, then they
probably should use something else.

Steven Peck
-sepeck

http://drupal.org/mission
http://drupal.org/principles

http://drupal.org/best-practices ----
Plan for the future. You should revisit and reevaluate your site each
time there is a major version release of Drupal. This does not mean
you have to upgrade it, but you should evaluate and plan for an
upgrade approximately each 12-24 months.