Welcome to django-productline’s documentation!

“build feature-oriented product lines for django”

django-productline provides a basis and some conventions to develop django web-application product lines. It follows the feature-oriented software development (FOSD) methodology.

Products i.e. specific web applications can be generated by selecting a certain set of features from a pool.

There are many definitions of what a feature really is. In the context of django-productline, we will use the definition of Apel et al.:

“A feature is a structure that extends and modifies the structure of a given program in order to satisfy a stakeholder’s requirement, to implement and encapsulate a design decision, and to offer a configuration option”

More information about FOSD can be found here:

I gave a talk on django-productline at FOSD Treffen 2013 in Dagstuhl (Slides).


With the concept of apps, Django already provides a pretty good modularization mechanism. Integrating an app into a project typically means to change multiple settings and registering the necessary urlpatterns. Some apps provide an API, so to integrate it properly additional code needs to be written.

When developing multiple django projects, you may end up doing this over and over for different projects in slight variations. Particular projects may also need specific additions and changes scattered across multiple locations in the codebase. Therefore, developing and managing multiple projects and copying with their variability can become a rather error-prone and time consuming task.

FOSD allows to encapsulate these additions and changes in features, which form a product line. Specific products can then be composed by assembling some of these feature.

The approach aims at improved reusability, traceability(where is all the code that relates to a specific feature), and automation.

At schnapptack, we use this approach for about a year to build specialized web applications for our clients and have found it to be a real productivity booster. Now, we want to iterate on the tools and scripts we have built internally and develop them in the open from now on. We are currently in the process of cleaning up our codebase and releasing it piece by piece. Also, we are planning to open source some of our core features, so other interested folks may also go product line.


A typical django web application consists of the following:

  • web server configuration of some sort
  • a set of external services
  • databases
  • application code
  • templates
  • javascript code
  • CSS

The goal is to be able to automatically compose entire applications i.e. all required artefacts out of a set of features. In the context of “automatical composition”, project-individual integration code must eliminated. Multiple applications can then share common features and differ in others. Generated applications need to be easy to manage over the rest of their product lifecycle(further development, deployment). Also, there needs to be support for managing the products` individual configurations e.g. webserver and database configuration.

Composition Mechanisms

To be able to compose the required artefacts for a product, django-productline makes use of multiple composition mechanisms:

  • Python code is composed using featuremonkey
  • django`s built in composition mechanisms
    • for templates(django.template.loaders.app_directories.Loader)
    • and static files (django.contrib.staticfiles.finders.AppDirectoriesFinder)
  • Templates are refined using django-overextends
  • Javascript can be composed using featuremonkey.js
  • CSS is composable by simple concatenation.

Getting started



Indices and tables