[CS3281] Development processes of open source projects – socket.io and Teammates

During the course of CS3281, I had the chance to work on two different open source projects, socket.io and Teammates. There are various differences between the nature of the two projects as well as the development processes.

Socket.io

As a popular framework for real-time communication on the web, socket.io has many characteristics of a good open source project:

  • Highly modular structure where different components are broken into self-contained sub-projects for better management.
  • Clear separation of concerns between the user-facing APIs and the underlying transport layer logic.
  • Each module follows the open-closed principle where the APIs are well-defined but the underlying implementations can be extended or updated in the future.

In terms of the development processes, there were no clear documentations on the process. Instead, we communicate our progress with our project mentor and get feedback directly. The Pull Requests tend to drag for days or weeks before it gets properly reviewed.

For a widely used project like Socket.io, the development process should be improved in terms of manpower. A possible way of this solving the issue is to recruit a dedicated team of people who had experience with the project and have the free time to help maintain the project. In the long run, there can be additions and withdrawals from the team but there should be always be more than a few developers there so that issues and pull requests can be handled in a timely manner.

Teammates

Teammates is a peer evaluation platform for project teams. It is widely adopted across the world in hundreds of institutions. As a project that came out of an educational institution (NUS) with a lot of human resources, it is quite different from a typical open source project maintained by a single developer or a few people. Some of the characteristics of the projects are:

  • Well-documented project architecture, features, development processes among many other documents for the project.
  • Actively maintained and updated by a large pool of students and a core project team.
  • The development environment is strictly defined where the developer need to use a standardized set of tools of specific versions.

During the development process, there are various documents to read and a number of guidelines to follow. The Pull Requests are reviewed actively within hours by the project core team with high requirements of the coding style and code quality.

A possible area of improvement is the automation of the code review process. Currently there is no cloud integration test to check for build errors, test cases and code styles. A CI (continuous integration) service could be added to automate the test process and check the code style against a predefined standard. For JavaScript, the coding style can be checked by integrating  eslint into the codebase and the CI, which saves the time for both developer and the reviewer for common styling issues like whitespaces and indentations.

Comparisons

  • Socket.io has only a few active developers hence there is no need for a comprehensive documentation for developers and development cycles are long. Whereas Teammates has many active developers so there needs to be well-defined guidelines and documentations for the new developers and the development cycle is very fast.
  • Socket.io is a mature framework used by many production systems, hence the features are relatively stable without significant updates. Teammates is a standalone platform that continuously evolve based on the feedback and requirements of the users, hence having more frequent updates.

 

Leave a Reply