Announcing Google Summer of Code 2021!

[burke (Burke Mamlin)]

@suthagar23

Shortened coding period - The coding period is reduced to 10 weeks from 12 weeks.

It’s too easy to set our sites high and end up with projects just finishing or 95% complete by the end of the summer, which greatly diminishes their chances of getting deployed and used by implementers. I’ve been suggesting that we aim for 10 week-long projects, expecting that there will be time allowed for unexpected delays along with time for testing, release, and documentation. Now we will need to consider what could be reasonably accomplished in 2 months if we are going to ensure that 90% or more of our projects are not just complete code-wise, but released & used by the end of GSoC.

@suthagar23

Evaluations - Next year onwards, there will be only two evaluations

This makes sense. A mid-term evaluation primarily serves as a mechanism to provide feedback and, if necessary, fail early for projects that are struggling. I mid-term evaluation is less helpful for projects that are ahead of schedule (just a reminder to heap praise on the student).

@suthagar23

Eligibility requirements - It’s accepting from a larger community not just accredited university programs

This is excellent and should be used as an opportunity to raise the bar & expectations of students, not to lower them.

@suthagar23

We have to start preparing the projects as we have to reduce the project requirements for GSoC 2021. It’s not actually diving the project into two parts but it depends on the overall project completion goals. (~175 hr projects - 10 weeks)

I’d suggest we aim for ~140 hours - 8 weeks of coding and at least 2 weeks for releasing, deploying, testing, documentation. Let’s try to make sure every OpeMRS GSoC project is set up for success: (1) students learning how fun it can be to write code & save lives and (2) leveraging our unique position to make direct connections for aspiring open source developers with implementers on the front lines of critical health care in developing countries.

@suthagar23

We should have a larger number of projects + mentors compared to the previous years, as this year we can get more students on board.

More is better, but I would advise quality over quantity – e.g., I’d gladly give up a year of 20 GSoC projects (with some projects not completing, some students less engaged, and many cases where the work of the developers is not directly appreciated by implementers) in exchange for 8 projects with stellar students starting a lifelong journey of enjoying open source coding and celebrating how each project is saving lives. While we can strive for 20 stellar students saving the world, I’d gladly give up on quantity if it helps us maximize quality for the students.

@suthagar23

Even the project time or coding period shortened, effort from mentors will not be half as much even though the project size is cut in half. We can’t expect two or more projects from a mentor, So it’s better to have different projects from more community members.

Totally agree. We’ve always tried to have a primary & backup mentor for each project and to limit mentors to a single project. That has worked well.

We have some really fun & cool opportunities in 2021.

• Frontend Development. The micro frontend squad has been hard at work building a frontend framework for OpenMRS that embraces a best practice approach to modern frontend development (e.g., leveraging ECMAScript’s standard for asynchronous modules, TypeScript, Carbon’s Design System, etc.) all in an approach that prioritizes FHIR and allows disparate frontend technologies (e.g., React, Angular, Vue, etc.) to play nicely together. There will be a growing number of opportunities to build out frontend features in this framework in 2021. This is the direction we’d like all OpenMRS frontend development to converge toward.
• Building an Analytics Engine. The Analytics Engine Squad is working to develop the foundation for a common approach to getting data out of our relational model into a format that can be a sliced & diced for analytics & reporting using contemporary tooling like Apache Spark, Debezium, etc. Our hope is this solution can be our initial foray into a microservice approach for the backend, providing some basic functionality out of the box with OpenMRS, yet able to scale into the cloud.
• Light GSoC on FHIR! The world is adopting FHIR as the standard for clinical information and OpenMRS is helping lead the way. The fhir2 module is here and an important strategy for OpenMRS moving forward to help us migrate to FHIR becoming the primary model for OpenMRS inside & out. There’s plenty of opportunity in expanding the fhir2 module to support more aspects of the FHIR API, especially those resources & features needed to support growing frontend efforts.
• Oh CIEL! The CIEL dictionary is the de facto standard for concepts in the OpenMRS Community. We’d like all implementations to start with CIEL and those needing to add concepts would first look to CIEL for their concept. But using all or part of the CIEL dictionary often involves manual effort & too much SQL. Fortunately, the Open Concept Lab (OCL) offers a platform to make dictionary management, including access to CIEL concepts, much easier. The OCL for OpenMRS squad is working hard on a client to leverage the capabilities of OCL for the OpenMRS community. There are opportunities in expanding the OCL client to support dictionary maintenance within OCL and to help Andy move his CIEL management & delivery into OCL.
• The last mile. Any implementer can attest to the sweat & tears involved in deploying and upgrading OpenMRS servers, especially at scale. The OpenMRS community is working on standardizing our deployment process, leveraging container technology like Docker. There will undoubtedly be opportunities to build and enhance deployment tooling in 2021. If it hasn’t already been addressed by GSoC 2021, our standalone could use some love.

@suthagar23

Org applications will open on January 29th.

Happy to help!

tl;dr Excited for OpenMRS in GSoC 2021!