Django Rework
(draft version, needs review)
This case demonstrates how the core functionality of a product can be customized, whilst keeping the existent original code base mostly unaltered.
This can become important in order to be able to customize a product without the need to maintain a separate code-base.
The main method used is hooking.
Use cases
- customize functionality of a product, whilst using original code-base
- integration of products into a greater system
- a central tool which manages several products / applications.
Although this sounds like a standard reuse scenario, the practice with Open Source Products is different, because
- Quality of the code-base (modularity, stability, terminology).
- Cooperation of the Team and the Community is not a given.
- access to the Open Source Project Resources is not a given
- (licenses guarantee only access to source code)
You can find the relevant code results in the Description Phase 4.
Description Phase 1
The initial Initial Product Evaluation identified several barriers on which newcomer could hit during the first setup.
Several suggestions for improvement were given. Django Product Fictional demonstrated how the implementation of the suggested changes would improve the user experience (e.g. reduced setup steps).
The work could not be applied easily, as no svn locations were available for intrested contributors (e.g. sandbox locations).
The existent team reacted negatively to the suggested changes and did not accept any of them. The discussion thread which contained the results and several suggestions was mostly ignored.
Both events together, the rejection of the patch and the non-availability of an SVN location, made the efforts essentially useless.
(Many other efforts from users get lost this way, see Patch review procedure? ).
Suggestions to provide flexibility (e.g. multiple project templates) were not accepted, too. It is intresting to review the answers to the multiple project templates suggestion in order to understand the barriers which can came up whilst trying to get a functionality into the central product version.
Description Phase 2
Without further access to the developer list, the next step was to simplify the changes further, thus interested users can test them.
Missing granularity (e.g. _get_sql_field_def) and extensibility of the django sources made this difficult.
This django-users-list thread introduced this version if the evaluation document.
The evaluation comes now closer to the Django Product Fictional, but the installation has become more difficult, as a patch must be applied manually in order to get the new evolve functionality.
Despite the clearly technical nature of the topic, the django leadership reverted my access-rights to the django-user list. Correction: my access
Important to Realize:
Most Open Source Projects do not grant a right to access the project resources. They can revert access privileges at any time, without a formal procedure. The only right is the access to the source codes.
The current rework case showcases how this can lead to difficulties during the adoption of an open-source product.
Find more details within the Liberal Project Definition.
Description Phase 3
Without access to people around django (developers, users), the need to simplify the verification of the results becomes even more important.
An unknown construct was requested on comp.lang.python. (This serves additionally as a showcase for the Abstraction Process
The resulting syncdb_hook.py includes the unchanged evolvedb.py elegantly into the existent source.
Reviewing the related Evaluation Document will show that the installation of the additional schema evolution support is now a simple copy operation:
$ copy /django/django/rework/manage.py manage.py
Still, the many inconvenient configuration steps required to setup a basic django project are annoying.
Description Phase 4
An own project template was provided, with several default settings for the users convenience.
The startproject_hook alters the existent functionality. (Note: "startproject" means essentially "createproject").
The additional/altered functionality is provided via one additional import statement in django-admin.py
The resulting Evaluation comes now close to the targeted Django Product Fictional]
The flexible project template, a suggestion which was not accepted by the team (see thread), was simply hooked to the existent code.
Of course there are not much arguments against a flexible project template system, but Open Source Projects have their own Goals, thus one has not to expect that enhancement suggestions will be rated as important.
Description Phase 5
- further simplification of functionality
- further simplification of installation
- verification of the evolve functionality
Results Phase 1 - Django Project Dependent
Problems/Barriers (to Creation / to Contribution):
- Project Processes do not engourage contributions
- Working with patches does not allow simpe verification of results
- Source Code difficult to understand (weaknesses: weak OO, Structure and Terminology)
- Missing support from Team and Community
Suggested Django Reworks
- Django Code Refactoring (DB and ORM Subsystems)
- Django Process Reengineering (Contribution, especially SVN / Patch)
Results - Phase 2 - Django Project Independent
- source:django/rework/evolve.py (implements "evolvedb" command)
- source:django/rework/add_evolvedb_command.diff (patch, adds "evolvedb" to command line)
Problems/Barriers (to Creation):
- Django Command Structure does not allow dynamic additions of commands
- "_get_sql_field_def" functionality not decoupled
Suggested Django Reworks
- Django Code Refactoring (Granularity, Genericity, Extensibility)
Results - Phase 3 - Django Code Independent
- source:django/rework/evolve.py (implements "evolvedb" command)
- source:django/rework/syncdb_hook.py (hooks "evolvedb" command on "syncdb" command)
Problems/Barriers (to Creation):
- Several unknown constructs
Suggested Django Reworks
- none
Results - Phase 4 - Django Code Independent
- source:django/rework/startproject_hook.py#13
- source:django/rework/django-admin.py#13
- source:django/rework/templates#13
Problems/Barriers (to Creation):
- none
Suggested Django Reworks
- none