Django – An Ethnographic Study of an Open Source Software Project
Posted in Tech .:. No comments yet
Django is a Python web framework – a collection of tools for developing web applications. Django was originally developed at World Online, the web department of a newspaper in Lawrence, Kansas, as “The CMS ”. The development team comprised of Adrian Holovaty, Simon Willison, and later Jacob Kaplan-Moss and Wilson Miner. Now an open source project, Django is run by an international team of volunteers, including core developers in all US timezones, England, and Australia. The Django development team forms a distributed software engineering team that leverages many aspects of the modern networked economy.
In the early days of non-networked computing, distributed open source projects like Django were not possible. However, the rise of the network society, as described by Manual Castells in “Materials for an Exploratory Theory of the Network Society,” has enabled a plethora of them. Castells describes the new society as networked, global, and informational. The Django Project possesses each of these aspects.
Networked: People and Employment
In describing the networked aspect of the new society, Castells posits that a new form of economic organization, the network enterprise, is at the heart of the global economy. This term describes “a network made from either firms or segments of firms, and/or from internal segmentation of firms” (10). He notes, for example, that small and medium businesses are connected in networks, and that “these co-operations are based increasingly on sharing of information” (11). Theoretically, anyone can contribute code to Django, but in reality it is a small enthusiast group of core developers that does most of the work. Nonetheless, like Castells describes, Django enables a network of individuals to make collaborative contributions and decisions. Further, by leveraging the Django framework, small businesses and even individual freelancers can provide services that at one point in history could only be offered by larger businesses.
The oversight that the core Django developers provide is essential to the project’s well-being. Without the guidance of these dozen or so developers, the Django project would be an uncoordinated collection of programmers without a unified vision. The core developers “are the folks who have a long history of contributions, a solid track record of being helpful on the mailing lists, and a proven desire to dedicate serious time to Django.” In return, they have permissions to commit (make changes) to Django’s source code.
Since there are only a handful of core developers, their time spent reviewing tickets (bug reports and suggestions for improvements) and patches (modifications to the source code) is a scarce resource. In the Django IRC channel, for example, cramm (screen name) laments about other developers attaching incomplete patches to tickets:
I don’t know how to feel abot [sic] people attaching patches to tickets that simplify things but at the same time break them. Then a core dev comes in one of her/his rounds sees only the broken patch and we’ve lost a chance of getting the thing fixed.
As another example, the run-up to a release is not the time to make feature requests since the core developers are busy finishing tickets milestoned for the release. A participant in the django-developers mailing list tried to float a suggestion for a new feature a few weeks prior to the 1.1 release and received a rather blunt reply from core developer Malcolm Tredinnick:
Look at the major contributors to this list and the people who have the deepest understanding of the platform. Now look at the list of people doing the reviews and commits to get 1.1 out. Notice the large overlap.
The Django developers form a network in which “nodes increase their importance by absorbing more information and processing it more efficiently” (Castells 15). The core developers are the most important nodes in the network since they process the most information and ultimately make all changes to the framework, even if the patch is contributed by a member of the community.
Having a global team of developers is ideal for finding specialists to develop specific areas of the framework. A company that hires exclusively in the area surrounding its headquarters limits itself to the interests of those in the surrounding community. In the opening section of Wealth of Nations titled “On the Division of Labor,” Adam Smith argues the merits of the specialization of labor noting that it increases dexterity through practice, reduces transition time between tasks, and the increases the likelihood that a person will find a method to automate the task to abridge the labor. In his work “On the Division of Mental Labor”, Charles Babbage extends these ideas to the the knowledge worker. The Django development team has several specialists who work on areas of Django that interest them. When I asked a question in IRC, for example, Alex Gaynor pinged cramm who he thought would be knowledgeable about my question: “cramm: you’re the rest expert, can you take a look at what timograham pasted.” Specialization frees individuals from the need to be fluent in the entire code base and allows them to innovate in specific areas of the framework.
On the question of employment in the networked economy Castells notes that “Most jobs are in fact not global, but all economies are under the influence of the movements of their globalized core” (10). True to this statement, most of the Django developers who work with Django professionally are employed near where they live. Some do work remotely, but this remains the exception rather than the rule. The Django community also allows developers to collaborate and develop a piece of software at a scale that would be unfeasible for a small business with only a few developers. Electronic Frontier Foundation board member Esther Dyson claims that “The fundamental thing (the Net does) is to overcome the advantage of economies of scale… so the big guys don’t rule” supports this assertion (Turner 219). While the core of Django was implemented by a small team at World Online, the major refactorings of the code base that have occurred since then would not have been possible if Django were not opened to the world.
While many of the Django contributors hold a professional stake in Django, others like college students participate for different reasons. Like the nonmarket work with new media described by Ito in her Digital Youth Research, Django is a place where young people have the opportunity to practice work. Nonmarket work “provides domains where youth can put [knowledge and skills] to practice in a context of accountability and publicity” (Ito). Possible motives for young people to volunteer on the Django project include a better chance of being accepted into the prestigious (and paid) Google Summer of Code program, as well as the opportunity to claim contributions to open source software on a résumé. My time studying the Django community overlapped with the application and acceptance period for the Google Summer of Code, so I encountered several student contributors to Django. The most notable was Alex Gaynor, a freshman computer science student at RPI, who is one of the top talkers on the Django IRC channel. I suspect his involvement with Django will most definitely “help [him] in [his] longer-term career aspirations” once he graduates (Ito). This collaboration of individuals, small businesses, and volunteers around Django forms a network enterprise.
Global: Collaboration – Virtual and Face to Face
The global aspect to Castells’ argument is fairly self-explanatory: global economic activities “have the capacity to work as a unit on a planetary scale in real time or chosen time” (10). Online tools such as wikis, mailing lists, and Trac (an online bug tracker) allow asynchronous collaboration, while the django-dev IRC channel allows developers to interact in real time. Even though Django’s developers are distributed across the globe, face-to-face meet-ups at conferences are vital for building community as well as working on Django itself.
Tickets are the process by which things get changed and fixed both in the Django code base and in the online documentation. For my initial interaction with the Django developer community, I decided to get a feel for the development process by working on some documentation tickets. At first, I looked for the easiest tickets such as typos. I was able to obtain a copy of the Django source code using the instructions on the Django wiki (documentation which is publicly editable, and any changes do not need to be approved), and the online documentation had information about the process by which tickets are triaged. Ticket triage describes the process of moving tickets from “unreviewed” to “accepted” to “ready for checkin”, and ultimately “closed” once the issue is fixed. Even though there isn’t a tangible reward, it was a great feeling once the patches I contributed were checked in. I appreciate the work that people before me have done, and it feels good knowing that my improvements will help someone else who is learning Django.
After a few weeks of working on small tickets I decided to try to contribute something more significant. I found several tickets for updates to the page describing third-party distributions of Django. I posted my ideas on refactoring the page to django-developers and received positive feedback from two core developers. I then created a ticket and a patch based on their suggestions. After a few weeks, I became impatient that there wasn’t any activity on the ticket so I marked it “Ready for checkin”. Ten minutes later, Alex Gaynor noticed my change, moved the ticket to “accepted” status, and left a comment: “Please don’t mark your own tickets as ready for checkin, it skips a vital review phase.” Well, so much for that… A few weeks later (about a month after I filed the original ticket and patch), Jacob checked in the change along with a collection of other documentation tickets. This episode demonstrates the limited time of the core developers, as discussed earlier. Through this episode, I also learned an important lesson: peer review is vital to high-quality open source software. Except for trivial changes, all patches should be reviewed by at least two developers, and the more significant the patch, the more reviewers should be involved. I think Malcolm put it best with his remark regarding his frame of mind when reviewing patches: “The bozo bit is on until proved otherwise”.
Speaking to the global distribution of developers, a conversation I witnessed in IRC reveals that as one core developer in Chicago drops offline for the night, it’s the beginning of the day for another in Australia. Even though the time zone differences create some awkwardness for real time communication, tasks like the ticket triage process can be done asynchronously using tools like Trac and the mailing list.
Software conferences are an important facet of the Django community. In fact, the decision to open source Django emerged from Adrian’s demo of “the CMS” at PyCon 2005. Conferences include keynote talks, tutorials, and a chance for community members to meet-up in person. Django had its first dedicated conference, DjangoCon, in September 2008 at Mountain View, California. DjangoCon 2008 was the first time that many of the core developers met in person, which I’m sure was a nice morale booster and enabled them to have a lengthy meeting to discuss the future direction of the project.
Typically, several days of “sprinting” follow a conference. The Django wiki describes a sprint as “an excuse for people to focus their undivided attention, for a set time frame, on improving Django.” Sprinting provides an opportunity for developers to meet and work face-to-face where they can be more productive than they might be working remotely. Local sprints are also organized spontaneously through venues such as django-developers. I encountered one on the mailing list in preparation of the release of Django 1.1 organized by Jeremy Dunck in Dallas. While the networked society has freed individuals from the daily commute to work, occasional face to face meet-ups with coworkers have become the new way to refresh and recharge.
Informational: Free versus controlled
By informational, Castells means that “the capacity of generating knowledge and processing/managing information determine[s] the productivity and competitiveness of all kinds of economic units” (10). Knowledge work is at the heart of the new economy, and the internet and related technologies, like Django, play an increasingly important role. Django evolves through “itch-driven” development and demonstrates that even though proprietary software dominates some market segments, the open source software industry has a viable future.
Since its inception, open source software has been viewed as emerging from developers “scratching an itch” to get something done. Jacob claims that the team at World Online didn’t start out intending to develop a web framework. Rather, they were just trying to solve the problem of fast-paced news publishing. This culture of itch-driven development continues today. In a posting to django-developers, Russel Keith-Magee explains how new features are developed:
If you’re not willing to write the code yourself, then you either need to convince someone to engage with the community and make it happen, pay someone to engage with the community and make it happen, or wait until it becomes a big enough itch for someone that it gets scratched.
The Django project’s decision making process is mostly democratic and, at last resort, dictatorial. The development is driven by the need to “get shit done” as Jacob says, and Django’s motto is “the web framework for perfectionists with deadlines.” Adrian echoes Jacob’s sentiments by stating the pattern of posing the question “What’s the need?” to a proposed change, and he asserts that “Nothing goes into Django without an explicit use case from someone who is trying to do something and can’t.” In response to a feature request on the django-developers mailing list, core developer Russ Magee writes “we will want to see public interest [in the proposed feature] and continued support as a standalone project before we commit to integrating anything into the Django core.” While core developers have a strong say in the development of Django, Jacob confesses to a time when “pretty much all of the core developers were against the idea, and all of the community was for it” and a compromise was made. Even though Adrian and Jacob have assumed the title “Co-Benevolent Dictators for Life” of Django, Jacob remarks that “we only rule by fiat when absolutely necessary.”
In “Architectures of Innovation”, Lawrence Lessig proposes “control vs. freedom” as the intellectual property debate of the 21st century (178). This debate extends to the realm of software: commercial and proprietary versus free and open source. During the time when the notion of open source software was gaining traction, Steward Brand pointed out the economic paradox of information: “information wants to be expensive, because it’s so valuable. [...] On the other hand, information wants to be free, because the cost of getting it out is getting lower and lower” (Turner 136). Django is licensed under the terms of the BSD license, a permissive license which can be summarized as 1) You are free to redistribute the software, in binary or source form, as long as the copyright, conditions and disclaimer are present and 2) You cannot use the name of the originating organization, or contributers, to promote derivative works of the software, without written consent. While a license like the GNU Public License (GPL) requires derivative works to be released under the GPL, the BSD is a compromise between the GPL and a proprietary license in that derivates of BSD licensed software may be licensed commercially. Many businesses, including World Online with their Ellington CMS for news organizations, have used Django as a building block for commercial products which they license to cover their open source development costs.
Time will tell, but I think the BSD can be a good compromise for corporations looking to give back to the open source community. There are other tangible benefits to open sourcing software. When the idea to open source Django arose, Jacob detailed a business case for open sourcing the framework: “open source will increase our visibility and lead to easier sales and easier hiring, open source will improve the quality of our software.” Interestingly, the most effective argument with management, according to Jacob, was a “moral” one: “how Open Source had helped our business (Apache, Linux, Python, etc.)” and how it was time to “give back” to the open source community. The story of Django makes Jacob “hopeful that this ‘hacker culture’ is in fact compatible with business culture”. He believes that most business are concerned with doing the right thing but don’t know what this means when it comes to technology. He also describes the people at World Online as very forward thinking, so this may be an indication of things to come.
Perhaps most hopeful aspect in the control versus freedom debate is Sherry Turkle’s perspective on the current generation that is growing up: “As they reach adulthood, today’s children are not going to approach the issues raised by these technologies with a sensibility that depends on there being one answer that must serve all purposes” (28). Programs like Google’s Summer of Code are no doubt an attempt to evangelize the merits of open source software to the next generation. Even though information is at the center of the new economy, it does not need to be restricted intellectual property.
Since leaving World Online, Adrian Holovaty has started a local news aggregation service, EveryBlock, which must be open sourced per the terms of the project’s grant. In response to how he plans to maintain a competitive advantage after open sourcing the product, Adrian asserts, “Our competitive advantage is that we’re an incredible team, and I’m sure we’ll come up with a way to feed our families.” The “software as a service” industry (charging for value added services like support rather than the software itself) is something to keep an eye on as the debate between free and proprietary software plays out. Due to the modern capitalist belief that “the whole world is best managed when divided among private owners ,” Lessig views the future of free content as dismal (183). However, I think and hope that people will see the merits of open source software, and I suspect that the future of the industry lies in a hybrid of free and proprietary software.
In his 1995 book Out of Control, Kevin Kelly hypothesized that the ideal corporation should be: “distributed, decentralized, collaborative, and adaptive” (Turner 203). While this vision has not quite materialized, the Django project certainly possesses aspects of it. Django has impacted the web developers across the globe by creating a rallying point for collaboration and community. A small group of core developers leading a larger global community has resulted in a valuable contribution to the knowledge economy.
References
Babbage, Charles. “On the Division of Mental Labour.” On the Economy of Machinery and Manufactures. London, 1832.
Castells, Manual. “Materials for an Exploratory Theory of the Network Society.” British Journal of Sociology. 51 (1) 5-24, 2000.
Ito, Mizuko. “Work.” Digital Youth Research: Final Report. http://digitalyouth.ischool.berkeley.edu/book-work. 2008.
Lessig, Lawrence. “The Architecture of Innovation.” Duke Law Journal. 51 (6) 1783-1801, 2000.
Turner, Fred. From Counterculture to Cyberculture. University of Chicago, 2006.
Turkle, Sherry. Technological Visions. Temple University Press, 2005.
No Comments Yet
You can be the first to comment!
Leave a comment