About Drupal

Mission

By building on relevant standards and open source technologies, Drupal supports and enhances the potential of the Internet as a medium where diverse and geographically-separated individuals and groups can collectively produce, discuss, and share information and ideas. With a central interest in and focus on communities and collaboration, Drupal's flexibility allows the collaborative production of online information systems and communities.

Principles

• Modular and extensible.  Drupal aims to provide a slim, powerful core that can be readily extended through custom modules.
• Quality coding.  High quality, elegant, documented code is a priority over roughed-in functionality.
• Standards-based.  Drupal supports established and emerging standards.  Specific target standards include XHTML and CSS.
• Low resource demands.  To ensure excellent performance, Drupal puts a premium on low-profile coding (for example, minimizing database queries).  Drupal should also have minimal, widely-available server-side software requirements.  Specifically, Drupal should be fully operational on a server with Apache web server, PHP, and either MySQL or Postgresql.
• Open source.  Drupal is based on the open source philosophy of collaborative free software development and is licensed under the GPL.  Drupal is itself open source and builds on and supports other open source projects.  Specifically, Drupal is coded in the open source scripting language PHP and supports as primary data sources the open source database formats MySQL and Postgresql.
• Ease of use.  Drupal aims for a high standard of usability for developers, administrators, and users.
• Collaboration.  Drupal development supports open, collaborative information sharing systems and approaches.

Usability aims

For developers Drupal aims for a development system that is:

• well-tooled with a system of hooks that provide ready means to accomplish most foreseeable coding aims that involve interaction with core elements

For administrators, Drupal aims to provide solutions that are:

• easy to install and set up so that there is a minimum requirement for specific technical expertise
• intuitive and self-explanatory so that administrators can easily find the configuration options they need
• highly configurable so that site administrators can present just the interface they wish

For users, all elements of the Drupal user interface should be:

• intuitive and self-explanatory so that users with minimal prior experience can easily discover, navigate, and use functionality
• uncluttered so that users are not faced with a difficult task of sorting the essential from the non-essential

History

In 2000, permanent Internet connections were at a premium for University of Antwerp students, so Dries Buytaert and Hans Snijder setup a wireless bridge between their student dorms to share Hans's ADSL modem connection among eight students. While this was an extremely luxourous situation at that time, something was missing. There was no means to discuss or share simple things.

This inspired Dries to work on a small news site with a built-in webboard, allowing the group of friends to leave each other notes about the status of the network, to announce where they were having dinner, or to share some notewhorthy news items.

The software did not have a name until the day after Dries moved out after graduation. The group decided to put the internal website online so that they could stay in touch, continue to share interesting findings, and narrate snippets of their personal lives. While looking for an appropriate domain name, Dries settled for 'drop.org' after he made a typo to see if the the name 'dorp.org' was still available. Dorp is the Dutch word for 'village', which was considered an appropriate name for the small community.

Once established on the Web, drop.org's audience changed as the members began talking about new web technologies such as moderation, syndication, rating, and distributed authentication. Drop.org slowly turned into a personal experimentation environment, driven by the discussions and flow of ideas. The discussions about these web technologies were tried out on drop.org itself as new additions to the software running the site.

It was only later, in January 2001, that Dries decided to release the software behind drop.org as "Drupal." The motivating factor was to enable others to use and extend the experimentation platform so that more people could explore new paths for development. The name Drupal, pronounced "droo-puhl," is derived from the English pronunciation of the Dutch word "druppel" which stands for "drop."

To learn more about the history of Drupal, see also Drupal videos from Drupalcon (2006) in Vancouver.

Development and support

As a communication center and project management space, drupal.org includes members who use Drupal as a personal website solution; IT professionals implementing Drupal for clients; and programmers, writers and others contributing to the growth of the Drupal open source project. Members work together to maintain extensive development and support resources on site:

• Support. Users experiencing difficulties installing and configuring Drupal should first consult the administrator's guide, much of which is also available through help in the administration section of every Drupal installation. In cases where documentation fails to provide a solution, search the support forum and drupal-support mailing list archives. If the solution is not available, please write a detailed description of the problem, include the Drupal version number, and post it to either venue. Note: all support is provided on a volunteer basis and is dependent on the good will of community members; please be patient with any support requests.
• Development. The Drupal developer's guide contains information on Drupal architecture, API specifications, guides for theme and module developers, and instructions for contributing your code to the project. The Bug tracker system should be used to submit bugs, ideas for new features, suggestions for improving drupal.org, and contributing ideas for usability and documentation. Those seriously interested in contributing to development should also consider joining the drupal-devel list.

Learn more

See the links below, the other sections of The Drupal Handbook, and the many discussions in the forums for more information.

Druplicon (the logo)

After Drupal had been created, an obvious matter was the choice and creation of a logo. Of course it would have to do something with a drop... or water.

The inital idea was simple: a drop in a circle. . It was featured as an "O" in a liquidish "Drop".

When the community grew, the idea came up of a cartoony drop with a face. Steven Wittens (UnConeD) created a 3D drop, but the idea didn't get too far mainly because 3D is hard to print, hard to edit, etc.

When the logo-issue had come up again, Kristjan Jansen (Kika) came up with idea of putting two side-way drops together to form an infinity-sign. When put into a filled circle, it resembled a face. After some more work by Steven Wittens, the Druplicon was created: a stylised drop with the infinity eyes, a round nose and a mischievous smile.

That's the 'story' behind it... I like the idea that the infinity-eyes symbolise the infinite possibilities that Drupal offers :)

See more versions of the logo in the marketing section.

The Drupal core

• Founder and Lead Developer. Drupal was founded by Dries Buytaert, who retains primary control over the software and makes most decisions on proposed changes. In approving or rejecting proposals and patches, he gives special weight to comments made by individuals whom he trusts and respects based on their past contributions to Drupal.
• Core committers. A small team that reviews proposed changes and maintains code. They are the only ones who have write access to the core CVS repository.
  • Permanant core committers
    Permanent core committers are Dries and Steven.
  • Branch maintainers
    Individuals are designated as maintainers of a particular branch of Drupal core. Current branch maintainers are Gerhard Killesreiter (killes) for 4.7.x and Neil Drumm (drumm) for 5.x. See this post for details.
• Maintainer. While not directly making decisions, maintainers have informal responsibility for a designated portion of the core (e.g., a particular core module). Individual areas of responsibility are listed in the file MAINTAINERS.txt. Maintainers are appointed by Dries. Core contributors who have made substantive contributions (particularly to a core component not individually maintained) may apply for Maintainer status by writing to Dries; Dries may also individually invite them.
• Core contributor. Core contributors are those who contribute code patches or documentation for the Drupal core, contributions that are peer reviewed and then decided on by Dries or another of the core committers. It should be noted that anyone can submit patches against Drupal core.

Contributions

• Contributions repository manager. The CVS repository of Drupal non-core "contributions" (mainly, modules and themes) has a maintainer, who reviews and approves applications for CVS access, and one or more other team members who fill in when the Maintainer is unavailable or otherwise occupied.
• "Contributions" contributor. "Contributions" contributors develop and maintain "contributed" code packages that are hosted on the Drupal site but not part of the Drupal core. A contributions contributor has applied for and received write access to the "contributions" CVS repository. Contributions contributors are improving the overall reach of Drupal by producing and sharing enhancements that can be used by others. Contributions contributors are generally listed in the README or CREDITS files included in module and theme downloads.

Documentation and support team

Documentation and support is collaboratively provided by the Drupal community. Members span all Drupal roles and skill levels. Remember that you are dealing with people, so etiquette matters. References:

• The support tab gives an overview of support.
• The documentation handbooks provide the on-line written documentation. See also Tips on using documentation handbooks. If you want to help, see Contributing to documentation.
• The support forum area contains support discussion boards. See also Tips for posting in the forums.
• The development mail list is for Drupal developer support.
• The documentation mailing list is for documentation development.
• The IRC (Internet Relay Chat) system hosts several support channels.

Users

• User. Users are the people who use Drupal. Users don't generally contribute code but make valuable contributions by submitting bug reports or feature requests through the issues system (http://drupal.org/project/issues) and participating in the drupal.org forums (http://drupal.org/forums)

Security team

Goals of the security team

• Deal with reported security issues.
• Constantly review the code for potential security weaknesses.
• Provide assistance for contributed modules' maintainers in dealing with security issues.
• Provide documentation on how to write secure code.

How to report a security issue

If you discover or learn about a potential error, weakness or threat that could compromise the security of Drupal, please mail your concern to the Drupal security team: security@drupal.org. Please provide as many details as you can about the environment, Drupal version, modules used, their versions and so on.

If you are required to encrypt your report, use the OpenPGP key: 0xA1FDFAC2.

How we deal with reported security issues

• Review the issue and evaluate the potential impact on all supported releases of Drupal.
• If it is indeed a valid problem, the security team is mobilized to eliminate it.
• New versions are created and tested.
• New packages are created and uploaded to Drupal.org.
• We will utilize all available communication channels to make it known that a security issue has been found and fixed, and what steps must be taken by Drupal administrators to protect themselves.

Disclosure policy

Our policy is one of full disclosure; we will never withold information about a security problem and hope that it won't be discovered by others. However, public announcements will only be made when the threat has been addressed and a secure version of Drupal is available. We ask that when reporting a security issue, you observe these same guidelines, and beyond communicating with the security team, do not share your knowledge of security issues with the public at large.

Which versions are supported?

• Not all historical versions of Drupal are actively supported only the current and one back (at this moment these are 5 and 4.7). Versions of Drupal that are not actively supported will not get security releases. It is therefore not recommended to run unsupported versions of Drupal. Please upgrade so that you will benefit from security releases.
• The development branch of Drupal is not intended for production use and while security problems are fixed, security announcements are not issued. If you are using the development branch for testing or evaluation, we assume that you will update your code regularly.
• The security team oversees the security of the code found in the core Drupal distribution. The security of contributed modules and code lies with the individual maintainers. See the process below.

Issues with contributed modules

As soon as we learn about a security issue with a contributed module, we forward that to the maintainer of said module with a deadline. As soon as the maintainer fixed the problem, the security team will issue the relevant advisory with instructions on how to upgrade. However, if the maintainer does not fix the problem within the deadline, an advistory will be issued nonetheless, but we will advise to disable the module and we will disable the project as well.

How to get involved?

The most important help you can provide is reviewing proposed patches with a security mindset. You can also help by reporting issues and working with the team on a fix.

Security team members

• Khalid Baheyeldin
• Dries Buytaert
• Robert Castelo
• Heine Deelstra (team leader)
• Robert Douglass
• Neil Drumm
• Uwe Hermann
• Ayman Hourieh
• Morbus Iff
• Thomas Ilsche
• Bart Jansens
• Gerhard Killesreiter
• Andy Kirkham
• Erdem Köse
• Kieran Lal
• Karoly Negyesi
• Adrian Rossouw
• John VanDyk
• James Walker
• Moshe Weitzman
• Matt Westgate
• Steven Wittens
• Derek Wright

Hitchhiker's guide to the Drupal community

So you've decided to jump in and hitch a ride with Drupal? That's great! The Drupal community welcomes everyone who uses the application for their own needs, be they personal, corporate, community-based, or otherwise.

Whether you contribute back to Drupal or not, the crew enjoys having your company: after all, it is a very long journey. They also know that many of you do your bit by recommending Drupal to others.

All of you count, because you all contribute to the size of the Drupal community - and the more people there are, the bigger Drupal is, and the better it becomes.

What's more, it is understood that you have to be a user before you can become a contributor, and that many of you have the potential to contribute your own valuable skills to Drupal, once you've learnt a bit more about how it all works.

However, you should realise that you're benefiting from the generosity of hundreds of other people who have made Drupal the great platform that it is, and you're doing it at no cost.

All that is asked of you is that you appreciate the time and effort that others have put into Drupal on your behalf, and that you abide by one basic rule of etiquette:

Don't start making demands!

Drupal is a volunteer effort. You're welcome to suggest features. You're welcome to point out bugs or usability problems. You're welcome to politely ask for help. But do not angrily rant about the features that Drupal lacks and that you require of it, and then demand that "the developers" address said shortcomings as soon as possible.

This is a good way to annoy the rest of the community, who do not deserve to have their countless unpaid hours of service rewarded in this manner, and to find yourself without any further support.

As a member of the community you have no obligations to any other member, but neither do any other members have any obligations to you.

Even if you don't code, there are many ways to contribute to Drupal, participate in the community and influence development. A good place to start is to read these pages:

Drupal.org README first
HOWTO: Enact change within the Drupal community

How non-coders and new users can contribute to Drupal

Frequently, people complain that the process of contributing back to Drupal is overly difficult.

Additionally, people say that the Drupal community can feel unwelcoming.

So, some good news. If you're reading this, you are part of the Drupal community. Welcome!

And, if you're a non-coder and/or a new user and want to contribute, here are some ways to start.

1. Help out in the forums. The following forums see a pretty good share of questions from new users who need some guidance about how to use Drupal.
   • Pre-installation questions
   • Installation problems
   • “How do I” style questions

   Often, the questions in these forums are from users who are having hard time getting their heads around exactly how to use Drupal. People new to Drupal have a perspective many experienced users lack. As a result, new users are often the most effective at helping fellow newcomers.

2. Take a look at the mailing lists. All of the mailing lists are archived; while reading through the archives is not for the faint of heart, it gives some good insight into the level of thought going into the Drupal project. If you want to contribute further, join the Documentation or the Support list. Both of these areas have opportunities where non-coders and new users can help out.
3. At the risk of sounding like an etiquette manual, help keep the tone civil. Many people who post questions in the forums are frustrated, and that frustration shows in how they ask their question. Often, instead of asking a question, people rant, make demands, blame others, bait others, or do any number of things that are less than socially appropriate. While there is a very understandable temptation to give some questions the answer they deserve, please don't. Flame wars detract from the drupal community, and they can scare off new users. Keeping the tone civil and constructive helps ensure that new users will feel comfortable asking questions while getting started.

So, welcome aboard, and thanks for your contributions to the Drupal project.

HOWTO: Enact change within the Drupal community

A lot of people have a lot of suggestions for how the Drupal community could be improved. This is fantastic, as it shows that people genuinely care about Drupal, and want to see it improve.

However, it is unrealistic to expect every request to be implemented. Drupal is a community of volunteers, and since there are more things to be done than there are people to do them, those volunteers are forced to pick and choose their battles. Changes also take time; even changes which are "technically" simple (such as enabling a module or two on Drupal.org) need to be given consideration in terms of how useful they will be to the community as a whole, whether there are any adverse effects to doing so, and whether or not effort is best spent there or in another area which may have a greater long-term benefit.

Therefore, a much better and more effective approach than merely asking for change is to take steps to enact change yourself. "Own the problem" -- if you see something you don't like, resolve that you will do what you can to help fix it. Drupal's community provides countless ways in which to do this: participating directly in development discussions, adding or submitting corrections to handbook pages, submitting modifications to modules, and so on.

The success of how your ideas are received depends a lot on your approach. While there is no guarantee that an idea will be adopted into the project, here is an outline of steps detailing the best practice method that more experienced members of the community tend to follow in order to get their ideas heard:

1. Inquire
Ask "why is this like this?" Don't make assumptions. Maybe there's a good reason. Try to find out who the people are behind the decision-making process for your particular issue, and talk with them to see if there's a way to create a solution that both meets your own needs and satisfies the existing requirements.

2. Research
See what other solutions are out there that you might be able to extend to meet your needs. See how other people are handling the problem you're currently facing. Talk with other community members to see if they see merit in your idea, or if they have an alternate approach.

3. Propose
In as much detail as possible, outline the steps to fix the problem. Do a mock-up of what you think the solution would look like, and describe how it would work. Anyone can propose an idea. "I think Drupal should do this." Great! But an idea that has been researched, that is backed up with a plan, and which is able to quantify its purpose and effectiveness is far more likely to get attention and to later be implemented.

4. Refine
Get feedback from the community, as this can often improve upon your original idea. Take criticisms and either address them or incorporate them into your plan.

5a. Be patient
Depending on how well you've written your proposal, you might catch the eye of a developer who says, "Yes! I know exactly what you mean, and I want that very thing too!" You might catch the eye of someone with money who says, "Yes! I will pony up $500 to put into a pool for that feature!" which will in turn attract a developer.

However, bear in mind that change in the Drupal community is evolutionary rather then sudden and immediate. Change occurs over weeks and months rather then days and hours. Discussion tends to occur in a time lagged fashion on the forums and through email over time in collaboration. It's not just one person that makes the decision, it's generally a group consensus. Keep in mind that while your proposal makes sense to you, it may not make sense to a majority of others at first.

5b. Be willing to DIY
On the other hand, you might receive luke-warm acceptance, or you might get a lack of response because people don't fully understand your idea and how it would work. Sometimes the best matter is to take things into your own hands, and Drupal.org gives you literally dozens of opportunities to do so. You can:

• Submit a patch via the projects system to improve modules
• Engage in discussion with developers via the mailing lists to improve infrastructure
• Submit documentation with the handbook system to improve documentation
• Put forward money to hire a developer who would otherwise be working on something else to address your issue.

....and on and on and on.

By contrast, here are some things that will NOT help enact change:

Accusations
Some people take the approach of talking in a very accusatory manner toward developers, implying that they are lazy, selfish, uncaring, and worse. Nothing will make people less sympathetic to your cause than taking this kind of attitude toward them.

Demands
No one from this community is being paid by "Drupal" to do work, so they tend to go after issues that interest them, or issues that they're being paid by their employers to address, and so on. That may mean that no one has the interest or the time to fix your specific issue. Either accept that, or take steps to fix the issue yourself, as outlined above. Demanding that it be done only makes people less willing to help.

Impatience
Rome wasn't built in a day, neither was Drupal, and neither will be your brand new concept. Things take time in order to be properly thought-out, planned, and implemented. Accept this, do not be frustrated by it. If every idea was thrown in willy-nilly, we would not have the stability of a system which we all know and love.

Does this sound like a lot of work? You're right, it is. While none of these steps need take a ridiculous amount of time and preparation individually (an "inquiry" could be a 5 minute conversation on IRC, and a "proposal" could just be a forum post), it requires free time, energy, patience, commitment, and skill to see changes through. And even after all of this work, sometimes ideas *still* aren't implemented for various reasons (read more on the decision-making process at http://drupal.org/node/10261). So try to realize that it is really pretty unreasonable to expect other people both to have all of these qualities, AND to be willing to drop everything and work on your specific issue, all at no cost to you. Have some compassion for the fine folks running and participating in the Drupal community, and take responsibility to do what you can in order to make it easier for your ideas to see the light of day.

Welcome to the community!

Gallery: Images and links to the home pages of Drupal sites

Take a moment to visit some exceptional Drupal websites that exhibit the versatility of this tool. These sites display how Drupal sites can be built to meet many different functions and needs while still being graphically appealing and dynamic.

Case studies: descriptions of different types of sites and links to them

Drupal meets the needs of different types of web sites:

Community Portal Sites If you want a news web site where the stories are provided by the audience, Drupal suits your needs well. Incoming stories are automatically voted upon by the audience and the best stories bubble up to the home page. Bad stories and comments are automatically hidden after enough negative votes. Examples: Debian Planet | Kerneltrap

Personal Web Sites Drupal is great for the user who just wants a personal web site where she can keep a blog, publish some photos, and maybe keep an organized collection of links. Examples: urlgreyhot | Langemarks Cafe

Aficionado Sites Drupal flourishes when it powers a portal web site where one person shares their expertise and enthusiasm for a topic. Examples: ia/ | Dirtbike

Intranet/Corporate Web Sites Companies maintain their internal and external web sites in Drupal. Drupal works well for these uses because of its flexible permissions system, and its easy web based publishing. No longer do you have to wait for a webmaster to get the word out about your latest project. Examples: Sudden Thoughts | Tipic

Resource Directories If you want a central directory for a given topic, Drupal suits your needs well. Users can register and suggest new resources while editors can screen their submissions. Example: Entomology Index

International Sites When you begin using Drupal, you join a large international community of users and developers. Thanks to the localization features within Drupal, there are many Drupal sites implemented in a wide range of languages. Examples: PuntBarra | cialog

Education Drupal can be used for creating dynamic learning communities to supplement the face-to-face classroom or as a platform for distance education classes. Academic professional organizations benefit from its interactive features and the ability to provide public content, member-only resources, and member subscription management. Examples: ENGL 420S | WPA

Art, Music, Multimedia When it comes to community art sites, Drupal is a great match. No other platform provides the rock solid foundation that is needed to make multimedia rich websites that allow users to share, distribute, and discuss their work with others. As time goes on, Drupal will only develop stronger support for audio, video, images, and playlist content for use in multimedia applications. Examples: Terminus1525 | Project Opus