Personal tools
You are here: Home About Open source project management and administration
Document Actions

Open source project management and administration

by xavier last modified 2009-06-16 16:09

Open source softwares are developed and maintained by international groups of volunteers. Like many open source projects, Plone and Zope have adopted a culture of agile development. How does an open source project operate? Describing the methodology of code and development, process and legal organization.

Code and Development

Open source developers speak with code.  Thus, activities related to the software artefacts are the essential glue for the project.

  • Subversion : The source code is managed in a version control repository.  This allows tracking of every change, rolling back changes to a previous version, and trying new ideas in isolation from the main development activity.
  • Unit tests : The world of Zope had adopted a culture of quality focused on testing. With this approach, the developer writes a test before writing their code.  Also, since Zope and Plone have thousands of tests, the developers can determine if their changes have negative impacts on other parts of the system.
  • Mailing lists : Developers and users can communicate with each other and hold discussions that are then archived and searchable for later research.
  • Bug tracker : All issues get a permanent identifier and classification information.  As work is done to close the issue, reports are generated and communication about the issue is saved.
  • Release manager : Each release is managed both by a process that defines when code is frozen and also by a release manager that controls the list of changes and the timelines.
  • Collective : Common add-on products are shared in a repository known as the Collective, so named because anybody in the Collective can work on anyone else’s code.  This provides a common culture of development.  It also serves as a proving ground for new features that might one day become part of the Plone core.

Process

As the Plone project grew, the need arose for ways to organize and evaluate work before changes become permanent.   Equally important, distributed volunteers need social interactions to understand each other’s intentions and motivations.

  • Conferences : Each year, the Plone community has an international conference. Combined with other conferences, like the two Python events, the Plone community has a forum to give presentations and network with other businesses and developers.
  • Sprints : Many times a year, the Plone developers will schedule a small, week-long get-together to focus on a particular aspect of Plone development. This is called a sprint, as the goal is to collaborate face-to-face on a unit of work small enough to be completed in 5 days. Sprints provide a powerful way to instill a common culture in Plone.  They also give developers the pleasure of working alongside other very talented people from a multitude of countries.
  • IRC : Internet Relay Chat (IRC) is a real-time text messaging facility, allowing developers worldwide to ask questions and dialogue with each other.  It has no cost and hosts many different forums, including a forum for Plone.  In addition to serving as a medium for technical information, IRC is a place that serves, quite literally, as the “office” for Plone.  People can say hello to each other, share success stories as well as frustration, and feel like a daily part of a real activity.
  • Bug days : When a new Plone release goes into testing, the developers schedule “Bug Days”, where a selected date/time is used to gather many core developers and users to report and fix problems in real-time.
  • PLIPs : New releases are governed by feature requests and architectural changes.   These changes are proposed as “Plone Improvement Proposals” (PLIPs).  Each PLIP has an identifier, common metadata, and a process that it must go through before work is approved and development may commence.  Completed PLIPs form the “What’s New” for a new release of Plone.

Legal and organization

Since Plone has become strategic to thousands of organizations worldwide, the legal status is critical.  The Plone Foundation was created in 2004.  The Foundation’s mission is to “protect and promote Plone”.

  • Board : The Plone Foundation has 9 board of directors.  Conference calls are scheduled twice-monthly with a published agenda and minutes.  The board is responsible for drafting resolutions for voting and approving administrative work.
  • Membership and voting : Like the Apache Software Foundation, the Plone Foundation membership is granted based on meritocracy.  Applicants propose their merit credentials and are approved by the membership committee.  Major policy proposals are voted on by the full membership, which represents the interests of developers, users, businesses, and organizations.
  • Executive director : The Executive Director job is to do the work approved by the board and to manage ongoing operations.
  • Committees : The Plone Foundation has a number of permanent committees (membership, intellectual property, and trademark) as well as ad-hoc committees.
  • Legal counsel : The Plone Foundation has legal representation from Eben Moglen at the Software Freedom Law Center (SFLC).  The SFLC was started by the Open Systems Development Lab (OSDL, the employer of Linux Torvalds) to give pro bono legal representation to important open source projects.  Eben is best known as the long-time counsel for the Free Software Foundation (FSF).
  • Trademark usage : As Plone becomes a market as well as a product, it is important to maintain a level playing field by preventing abuse of trademarks.  The Plone Foundation tasked Zea Partners with registering, in the Foundation’s name, the trademark in most important jurisdictions worldwide.
  • Contributor agreement : Eben Moglen proposed for Plone a model called “conservancy”, where the Foundation becomes the legal owner of all code and other assets.  This requires a strong contributor agreement and a process to ensure that all code can be traced.

Source

http://www.zeapartners.org/about/methodology