Reflection on the Open Source Process: True Groups

Hello! Welcome All! This post is focused on reflection on our past 3 months as an engineering team working on the Open Source project of True Groups.

True Groups originally began in a meeting discussion between a fellow Computer Science professor and student focused on beginning the process of creating a platform to help revolutionize the way that current class groups were being made. The reality of most group making, especially in a collegiate setting, is that they are made with their controlled limiting factor being whether or not group members are already close friends with one another. Some issues with this tactic include, but are not limited to: 1) It fails in New Classes where students don’t know each other. 2) It’s not guaranteed to lead to the most effective groups. 3) It may lead to ineffective work distribution among the group members. 4) It perpetuates racial, gender and other social divisions in selected groups.

By focusing on attempting to solve these issues, a group of 4 senior software engineering students at Notre Dame (Seun, Eddie, Joel, and Allen) created Truegroup; an open source project, designed to be built on by others.

As we were new to open source work, the first parts of the project were tailored towards clarifying our idea, doing research into what was already available, and designing a better solution. We found that there was no current way for professors and students to create classes that provided both information about the class and the groups they were in.

Once we formulated our idea, our team began by setting up the project ecosystem and utilizing software frameworks and tools to help us with the project. As a team, we also spent time extensively researching the licensing that we wanted to use for the project.

We decided to create a React Frontend, with a Node Back end and a Postgres Database to make the project. We used tools such as Github to host our project code, Trello for tracking tasks, CircleCI for continuous integration, Docket for continuous deployment and Heroku for hosting. We also used Gitter as our main mode of communication.

The positive part of our time on the project was that it was an original idea and so it gave us complete freedom to navigate how we felt best. We tried to implement best engineering practices but definitely gave more compromises knowing it was an open source project. The goal of open source is to make projects that others will want to build on, and one challenge that we continuously faced was coming up with a platform that not only deals with these issues, but also entices others to want to contribute to it in the future. Overall, we truly believe that we received the full open source experience including not being in the same city, but instead holding daily standups to clearly communicate as a team.

There is definitely a newfound respect for the entire open source community that consistently produces quality innovation in a way that encourages all to engage and contribute.