Keeping Open Source Open

It is assumed that to contribute to a piece of open source software the first thing you need to know is how to write code. The early contributors to the Drupal project were all developers and due to the incomplete nature of the software they all had to be able to contribute their own code to make the system fit their needs. This typical pattern continued until a rubicon was passed. Suddenly the tool had become complex and complete enough for someone without a programming background to set it up, configure it and create a non-trivial site with it. At this point the nature of the community changed forever. Suddenly there was a vocal group that wanted the system to work in a certain way, but didn’t have the skills themselves to make it do what they wanted on their own.

How did the Drupal community adapt to support a growing community of users who aren’t able to contribute directly to the software’s code?

I will examine the steps the Drupal community took to include these users in the project. Some efforts have failed, others have succeeded in unexpected ways. The end result has been a community that has historically included as many self-taught amateurs as it has professional developers.

I will also look at Drupal 8 and what it may mean for these efforts. Drupal 8 can be seen as a professionalization of the project. Spaghetti has been replaced with well-designed object oriented systems. Standards have been applied, outside projects included and more predictable and rigid systems have come to replace the easily hackable ones.

What does it mean for a community full of hobbyists when the system they rely on adopts paradigms that may be more difficult for them to understand? How has the Drupal community responded to the needs of the hobbyists? What does this mean for the future of Drupal?