Chapter 9

The journey does not end after a software project has gone live. This week’s reading was “Continuing the Journey” - Chapter 9 of Client-Centered Software Development. It focuses on the process of ensuring the long-term viability of software for the client and the broader open source community.

Many of the ways through which this is achieved have surfaced throughout our semester-long project. One of these is avenues for community communication once the product has gone live. This can take the form of both user forums and developer forums. These public forums and other organizational considerations come into play as an open-source product grows. Our chosen open-source project, Zulip, is a group chat application. It has created a server within the application where project contributors converse about issues and ideas. The server is a place for developers to strategize about bug fixes and feature enhancements. They decide which ones to prioritize and even which ones are necessary. Developers can also propose their new ideas which others will either support or question. Zulip’s userbase and developer base overlap, so there is not a separate forum on the user side. Instead, there is a lot of helpful documentation available.

The chapter also explains that as projects mature, the people associated with them diverge into a structure of users, contributors, and commiters. In this class, we are contributors, but we do not have the authority to push our changes. We must make a pull request containing our fix that a “committer” approves to be pushed. Commiters and contributors can be divided into roles such as the project leader. In our chosen software project, Zulip, the project leader is Tim Abbott. He developed Zulip and continues to be extremely active in the community.

The structure of Zulip mimics what the chapter coins a democractic meritocracy. This is a form of governance that FOSS projects can take on. Likening this to a traditional democracy, a meritocracy of contributors is akin to “the people”. I interpret this to mean that someone’s say in “political” matters will depend on his or her ability to contribute valuable code to the project. People who are more experienced with the project and coding in general will rise in the ranks and make the big decisions. In Zulip, this is someone like Tim Abbott. He is always the first to respond to pull requests; he determines whether they are valuable and makes suggestions or shuts them down if not.

Another area of discussion within this chapter that I could see clearly in Zulip is policies and procedures. These are developed as the project evolves to prevent conflicts between those at the head of the project. With clear guidelines about how issues should be identified and addressed, the project will be much more successful in decision making and conflict resolution. Community forums, such as the Zulip server in the case of our project, provide also platform for these types of discussions.

Much of this class focuses on the journey of software projects once they have gone live and truly enter the open source community development phase. Because of this, it’s interesting to compare how open source projects usually mature to Zulip’s path!

• 2021 11
• 2020 22