How the CAS Project Works

What is the CAS Project?

The CAS project was originally an open-source project run by Yale University. It has since become a JA-SIG project run by a myriad of universities including Rutgers and Yale.

What is JA-SIG?

JA-SIG is a 501(c)3 non-profit organization incorporated in the United States and was formed primarily to:

  • to provide education and research in the applied use of open technology architectures and systems in higher education
  • to develop a global academic community of interest among practitioners and institutions and to inform that community of international activities, projects, and opportunities in the field of open technology architectures and systems in higher education
  • to educate by coaching, collaborating, and sharing good practices, and disseminating the results of innovative approaches in this field
  • to create, through its various activities including conferences, projects, and outreach, an atmosphere of trust, goodwill, and mutual respect amongst all participants

Meritocracy

The CAS project follows the Apache Software Foundations definition of meritocracy.

Roles

The meritocracy enables various roles:

User

user is someone that uses our software. They contribute to the CAS project by providing feedback to developers in the form of bug reports and feature suggestions. Users participate in the CAS community by helping other users on mailing lists and user support forums. The passive users are also known as lurkers.

Developer

developer is a user who contributes to a project in the form of code or documentation. They take extra steps to participate in a project, are active on the developer mailing list, participate in discussions, provide patches, documentation, suggestions, and criticism. Developers are also known as contributors.

Committer

committer is a developer that was given write access to the code repository. Not needing to depend on other people for the patches, they are actually making short-term decisions for the project. Project Lead is in charge of long-term decisions with input from various committers.

Project Management and Collaboration

The CAS project is managed using a collaborative, consensus-based process. We do not have a hierarchical structure. Rather, different groups of contributors have different rights and responsibilities in the organization.

Communication

Communication is done via mailing lists. These identify "virtual meeting rooms" where conversations happen asynchronously, which is a general requirement for groups that are so geographically distributed to cover all time zones.

The project additionally use more synchronous messaging (for example, IRC or instant messaging). Voice communication is extremely rare, normally because of costs and the language barrier (speech is harder to understand than written text).

In general, asynchronous communication is much more important because it allows archives to be created and it's more tolerant on the volunteer nature of the various communities.

Decision Making

Projects are normally auto governing and driven by the people who volunteer for the job. This is sometimes referred to as "do-ocracy" -- power of those who do. This functions well for most cases.

When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.

Voting is done with numbers:

  • +1 -- a positive vote
  • 0 -- abstain, have no opinion
  • -1 -- a negative vote

The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote.

The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.

This process is called "consensus gathering" and we consider it a very important indication of a healthy community.

Philosophy

While there is not an official list, these six principles have been cited as the core beliefs of philosophy behind the project:

  • collaborative software development
  • commercial-friendly standard license
  • consistently high quality software
  • respectful, honest, technical-based interaction
  • faithful implementation of standards
  • security as a mandatory feature

Operation

The project is composed of volunteers and nobody is paid directly by the project for their job. There are many examples of committers that are paid to work on the project, but never by the projectthemselves, but rather by companies or institutions that use the software and want to enhance it or maintain it.

Based on the Apache "How It Works" Document: http://www.apache.org/foundation/how-it-works.html