FOSS and Software Engg education

Students Program
1

At IndiaFOSS 2024, Prof. Pankaj Jalote, Founding Director of IIIT Delhi, spoke about FOSS and Software Engg education. We (Prof. Pankaj and FOSS United) stayed in touch after the conference. Last month, Prof. Pankaj reached out to us to discuss the possibility of having the Software Engg course (insert missing link. maybe CSE 701) students this semester (Jan-Apr 2025) work on Indian FOSS projects and learn about software engineering in the process.

We reached out to a few projects from the FOSS United and the broader Indian FOSS community regarding this. We also put together two project proposals for the course (see Projects) We are happy to confirm that two teams (3 and 4 students in the teams respectively) will be working on the two FOSS United projects over the coming semester. We and the student teams will use this thread to share updates about our progress, and overall experience over the coming months. We’ve also invited the students to share their updates at the Delhi monthly events, to experience how their work directly impacts the FOSS United community.

@Harsh_Tandiya and I, along with the rest of the Foundation staff, will be working closely with the students to ensure the success of the projects. If successful, we (Prof. Pankaj and FOSS United) hope to take this experience to other academic institutes and work with them to update their Software Engg courses. Software Engg is a mandatory course in most/all CS degrees so enabling a systematic change will be a significant win for the Indian FOSS community (and FOSS United).

P.S. After IndiaFOSS 2024 is when I noticed that Prof. Pankaj Jalote was part of a panel discussion that @anand organized on FOSS in Education - ref Panel Discussion on FOSS & Education

Projects

Project name - Improving the performance of fossunited.org

Between 2020 and 2024, less than 50 in-person events were organized via fossunited.org. In 2024 alone, more than 50 in-person events were organized using the platform (fossunited.org). As the FOSS United Community grows, the performance of the website and the web application become crucial to the long-term growth of the Community. A significant number of performance improvements can be made to the platform - better adherence to modern web standards in the UI, improved architecture of the web application i.e. how the backend and the frontend communicate with one another, and performance profiling & improvements to the backend web application.

Project name - Improving the accessibility of fossunited.org

The FOSS community suffers from a lack of diversity - and diversity doesn’t only apply to gender diversity. While FOSS tools and internet standards empower visually challenged or handicapped computer users, there is a dearth of visually handicapped developers in the FOSS community. The first step in addressing this problem is to ensure that the platform meets the accessibility standards. The team will use publicly available tools to audit the accessibility of the platform and systematically improve the platform to ensure that it is accessible. Additionally, the team will put together references and guidance to ensure that new changes to the platform continue to meet the necessary accessibility standards.

8 Likes
2

Hello everyone!

I’m Tanmay Singhal, a 3rd year CS student at IIIT Delhi. I’m a fullstack developer who is passionate about open-source development and am excited to work on improving the performance of fossunited.org while learning from this community.

Thank you, Poruri Sir, for this opportunity to contribute to FOSS projects and learn from this experience.

Looking forward to working together!

1 Like
3

Hello, I am Rohak Kansal, 3rd year student at IIITD and am exited to start working on the project “Improving the performance of fossunited.org”.
I am looking forward to working with you all and learning from you.

1 Like
4

Greetings everyone,

I am Swapnil Panigrahi, junior CSE student at IIIT Delhi. I am very excited to work on this project to improve the performance of fossunited.org, and learn about software development at a production scale.

Looking forward to a great learning experience

1 Like
5

Hello Everyone!
Most of my peers did this discussion on time—sorry for showing up 3 months late. But I wanted to speak now, once we had truly begun contributing to the project. And here we are: the course may have officially concluded today, but unofficially, our contributions will continue.

Here are a few learnings I carry forward:

First—when you come with a mindset to give, you end up earning far more in return. This philosophy of giving, of knowledge-sharing, is not mine alone. It was instilled in us by Professor Pankaj Jalote, a visionary administrator. I may be too small and inexperienced to fully appreciate the depth of his foresight, but allow me to commit that crime anyway. He ensured we focused on learning instead of cribbing over marks. He opened his course to open-source collaborators so that both the community and the students could benefit. That kind of thinking shapes ecosystems.

Then came our hope in despair—our mentor and guide, Mr. Harsh Tandiya, and Rahul Sir.

Every time we came with silly questions (and we had many!), they were patient, generous, and always ready to help. They ignored our missed deadlines, guided us in our confusion, and hand-held us through setup nightmares—especially Frappe on WSL. (Pro tip: use Linux—WSL was pain. Harsh bhaiya still bore with us.)

Rahul Sir also introduced us to some of the experts working in accessibility, including developers from Red Hat. These interactions gave us real insight into practical, inclusive design. From learning GitHub workflows to discovering the value of accessibility, we grew.

Of course, we broke the codebase more than once (guilty), but we also learned how to fix what we broke—with patience, teamwork, and laughter.

This experience has been more than just a project. It’s been a journey of people, systems, and mindset.

We’ll continue contributing—outside the classroom, outside the deadlines—whenever we find time.

Thank you to everyone who made this possible. :pray:

2 Likes
6

Few Critical Suggestions & Feedback

Week 0: Open Source Orientation (A Strong Starting Point)

Before diving into technical contributions, it might really help to have a clear and structured introduction to how open-source workflows operate. A recorded video session (~1 hour) could walk through the basics:

  • Forking and cloning repositories
  • Creating issues and submitting PRs
  • Resolving merge conflicts
  • Git branching strategies
  • Commit message conventions
  • GitHub workflows—with hands-on examples

Instead of being purely theoretical, this could include a live walkthrough using a sandbox project (maybe something built in a previous cycle) so students can see the process in action.

If a resource like this doesn’t already exist, I’d be happy to contribute by creating one in my next contribution cycle—something future contributors could revisit whenever they hit a roadblock.

Week 1: Frappe Simplified — With Curated, Actionable Guidance

While there are many tutorials online for Frappe, I personally found it difficult to locate one that really explained the system well from a beginner’s perspective. The documentation exists, but unless you already know what you’re looking for, it can feel overwhelming.

To bridge this gap, perhaps we could:

  • Curate or create a tested, beginner-friendly video that covers:

    • Frappe’s core concepts
    • The different user roles and permissions
    • How Doctypes interact
    • Common triggers and workflows

  • Share a small, guided problem statement with students early on, encouraging them to build a simple 3–4 page app.

Once done, students could share their approach with mentors for feedback. This kind of exercise might help clarify misunderstandings early, and make the transition into the main project much more confident and efficient.

It would also foster meaningful peer and mentor interaction right from the start.

Linux Setup from Day 1 — An Early Enabler

A lot of us struggled with using Frappe on Windows Subsystem for Linux (WSL)—especially during bench build, which sometimes took up to 10 minutes per run and had to be repeated multiple times during each sitting.

To make things easier from the start, perhaps we can:

  • Recommend using a Linux environment (preferably through dual boot or a virtual machine) from Day 1
  • Offer a clear video guide and step-by-step written instructions for setting up a Linux system (e.g., Ubuntu)
  • Briefly explain why Linux works better with frameworks like Frappe and what issues students might avoid by choosing it

This small change could save contributors significant time and frustration, and help them get to the actual learning and building much faster.

If helpful, I’d love to contribute to such a guide or script as well.

Early Stakeholder Involvement — Making Projects More Aligned

In our own experience, it was a bit challenging to bring in stakeholders for accessibility reviews early in the process. We did our best to step into the user’s shoes, but timely feedback from real users could have helped us design more iteratively and accurately which is core of Agile Development.

Maybe in future editions, we can try to:

  • Identify key stakeholders in the very first week
  • Create channels or checkpoints to bring them in early for feedback
  • Align development with actual user expectations through small iterative cycles (as per agile principles)

This would make the projects not just technically stronger, but also more relevant and usable in real-world contexts.

Final Thoughts

These are just suggestions based on the challenges we faced and what we feel could help future contributors hit the ground running. With small shifts in structure—especially during the first month—we can turn initial confusion into clarity, and chaos into creativity.

Grateful for the learning, and always happy to contribute toward making the experience even better.

1 Like
7

I really enjoyed working with the team on the project, and it was definitely a great experience as well. I got to learn about a lot of stuff at the production level albeit some roadblocks here and there.
A few of problems we faced were:

  • Documentation: The documentation was lacking in a lot of ways, and we had to pool resources from a variety of different sources to get things up and running. I would really appreciate if that was worked upon so future contributors won’t have to face similar issues.
  • Communication Gap: This was more of an issue from our side as we were hesitant to trouble the development team with every tiny thing. One thing I learnt was to never hold back and ask as many questions.
  • Frappe Architecture: Since the project uses a architecture which isn’t mainstream, I would love if something like a one-to-one map could be added to show how the frappe architecture is working and in place with the code.
1 Like
8

P.S: its easier to figure out on your own other than on-loading someone else’s knowledge in you.

9

I wholeheartedly disagree

3 Likes
10

Why though ?

Especially in startups this is a really good opportunity to learn things the hard way. Figuring out everything on your own is quite very fun. There are ‘n’ number of benefits. If you’re a consumer product, customer support is the best place to start

  1. You get to know the system
  2. You make mistakes and newer mistakes
  3. If you do support, to answer the customer, instead of going to senior, open the codebase, read the code and suggest them potential fixes.
  4. Less reliability and dependency on others, they can really do their own work while just keeping an eye on your progress (hoping that’s done here too)
  5. You learn to reverse engineer and understand why certain design/construction choices were made.
  6. (case by case) If the other engineer has half-baked knowledge, why even bother to learn from them ? When you figure out on your own, you can understand and not really blindfold yourself into believing on others.
  7. “What I cannot create, I do not understand” - choosing between “understand on your own” or “understand from others knowledge and their way of learning things”.
  8. and so on…

Most of the engineers who don’t get to have KT, they have good experiences of learning. Imagine you figured out the system on your own, wrote a new function, but during the reviews reviewer told you that this function is redundant and there’s already an immature function which can be utilized. Agreed, frustrated and humiliating but humiliation is the best and straight forward way to learn things quicker.

Example: Maybe the above could’ve been done in this PR, but yeah just an example, slack it off happily.

1 Like
11

Everything you mentioned is true, but it requires time. Enormous amounts of time are needed if an individual needs to personally explore the entire system and “learn things the hard way”. And that’s not a privilege that everyone enjoys. Sure, time can be managed, and some make better use of it than others. But at the end of the day, there needs to be a balance between producing results and free-form learning. And documenting and sharing existing mental models of software (knowledge transfer) aids that balance.

Software is incredibly deep, and everyone is free to dig as deep as they are interested in on their own time. But when there’s an incentive involved (course credits in this case), we need to strike a balance.

If the author of the above Frappe Framework post thought that it was easier for others to figure it out on their own, I don’t know why they would have written it. The same goes for a majority of the software ecosystem - why are individuals wasting time writing documentation if they thought that it was easier for developers to figure things out on their own?

12

You conveyed what I indirectly convey in my reply. Time is the luxury folks in this thread have (the students I mean). Maybe they have assignments, exams and all the world is behind them for all the unnecessary tasks, but at least in the early days of career, everyone goes through these things right ?

Okay, so FOSS United is looking for output more than providing the students with an experience? Maybe, then my bad, I thought it was moreover a good balance between both. But eventually, at the end of the day, if someone is putting effort and time into X they surely give some benefit to themselves as well as their recruiting organization.

Agreed. But I don’t like the way every professional or every engineer forces or uses the word “Deep”. Software at times isn’t as deep as some X intern will hear from their senior (if “its deep” is conveyed by the senior). My seniors have always conveyed me that “its not deep”. When I digged in, I really understood the depth and stupid behavior of the code. It’s not really “curse of knowledge” which they have, but moreover its undermining the fact that “its code, and it will be dumb” and obviously not scaring the intern. Why don’t folks want to let the engineer/intern experience the depth ? Everyone out there is always talking about “Diving deep”, I say, just don’t say “diving deep” when you’re floating on the surface.

Also, I was never against documentation. When I said the person should figure out on their own, I’m just not standing for spoon feeding and it can be figuring out with any possible way. But maybe, I am in the wrong side because I think “learning to search, figure out and find your answers” is a bad approach early on in someone’s career.

1 Like
13

I cannot expect anyone (including students) to spend more than the expected number of hours - specifically because this work is tied to a course. If people want to spend their weekends and free time understanding a specific software system, that’s their prerogative. But coursework is usually tied to X number of hours, and we want to ensure that progress can be made within that period of time.

I don’t understand how you misconstrued me calling for a balance in such a way. Experience is practically unquantifiable. Courses need quantifiable information to evaluate progress and learning outcomes. The course is supposed to teach the students the basics of software engineering so the students need to practice software engg by opening PRs and making progress. If progress cannot be made because the onboarding process is difficult, how can we justify asking the students to pick our/any project?

Here again, I dont understand if you’re making a pointed comment at my remarks or about the general state of the software ecosystem. Software is incredibly deep - it’s just that most of the time we don’t need to dig deep to understand the behavior of the software system. We can look at a little bit of code and make an educated guess about the rest. That doesn’t mean that software isnt deep.

One more time - I don’t know why you’re conflating meaningful documentation with spoon-feeding or being against letting people figure out how to search and figure things out on their own.

I’ll say this again - the course objective was to help students understand and practice software engineering. And if the students aren’t actually able to practice software engineering and are instead spending inordinate amounts of their course time “figuring things out on their own” then the course objectives aren’t being met.

1 Like
14

Hello to everyone!
Finding the time to write this after how my semester finished and my internship started the next day has been annoyingly difficult (college has already started sounding fun again after a week of corporate), but I came back here to write this because I felt this program/project was a really nice learning experience for us, and that I should share my journey and thoughts along the way.

This project was full of firsts for us (the performance team). This was the first time any of us were working on a big, established codebase which was not started by us, but carefully built over the years by the efforts of the FOSS Community and the FOSS United team. This meant that we couldn’t just write code purely to build functionality without regard for understandability, performance, maintainability, etc.—we had to actually write code to a certain standard. We also had to write code the way the framework suggested—the frappe way—which meant using their functions and APIs rather than building our own (as their documentation suggests: configure, don’t code). All this took some time to get used to, as evident by the fact that when I started the project, I regularly failed the linter and/or the CI checks. However, it was a valuable learning experience that I feel I’m going to benefit from very soon in my internship, as the importance of code quality becomes even more paramount.

Another first was working with the (now familiar to us) model of weekly discussion meetings → GitHub issues → GitHub PRs and reviews. At first, it felt a bit rigid compared to how we usually wing it in college projects, but it quickly became clear how useful this structure was. Having a proper issue to discuss before diving into code meant we were always aligned on the why, not just the what. And the PR reviews—annoying as it was sometimes when you thought you were finally done—really pushed us to think through our choices, write better commit messages, and not ship half-baked fixes.

A thing that made this project stand out was its focus on objective metrics and improving an existing codebase, rather than building something from scratch. Our task was to make the fossunited.org website faster and more efficient — and that meant measuring real performance data using tools like Chrome DevTools, identifying bottlenecks, and then actually doing something about them. It wasn’t just about making it feel faster, we had to back our changes with numbers or logic. This also pushed us to seriously think about non-functional requirements like load time, responsiveness, and storage efficiency — stuff that usually takes a backseat in college projects where “it runs” is often good enough.

A huge part of what made this whole experience smooth and genuinely enjoyable was the guidance we got from Sai Rahul Poruri sir and Harsh Tandiya. Rahul sir, as our mentor, helped us stay on track with meetings and pushed us to think like engineers, not just coders. Harsh, being the lead developer on the website, gave practical feedback and helped us navigate the codebase whenever we got stuck. Their support really turned what could’ve been an overwhelming project into a focused and rewarding learning experience.

1 Like
15

I would also like to add some feedback regarding the program, which as great as it was, could do with some improvements for the future editions that other students can benefit from.

  • There were times when mentor unavailability led to delays in PR merges and issue discussions. While we understand that everyone has other commitments, but maybe having some backup reviewer(s) from the FOSS Community who are familiar with the codebase could help, especially if this program scales upto more than 2 teams at a time.
  • At the start, the codebase felt kind of overwhelming because there wasn’t much documentation or a guide on how to navigate it. A simple walkthrough or some high-level notes about how things fit together would’ve made it way easier for us to jump in confidently, although maybe this was a learning experience too, to dive into a codebase head-first and swimming through code till you understand how it does things.
  • The program could benefit from a clearly defined end-goal or success metric. For example, setting a concrete objective like “reduce the load time of the homepage by 30%” or “achieve a Lighthouse score of 95+” would help teams prioritize issues better and feel a stronger sense of purpose.
1 Like
16

Improving the performance of fossunited.org – Project Feedback

Contributing to this open-source project was a truly rewarding and eye-opening experience for me. As my first time participating in an open-source initiative, I had the opportunity to not only improve my technical skills but also gain insight into real-world collaborative development processes.

Our team’s primary focus was on improving the performance of an existing open-source website. This gave us the chance to analyze a live codebase, identify bottlenecks, and implement meaningful changes that had a tangible impact. Working alongside other contributors and receiving support from the maintainers helped me better understand best practices in performance optimization and code quality. The exposure to performance testing, documentation, and code reviews added substantial value to my learning journey.

One of the most valuable aspects of this experience was understanding how open-source communities operate—how contributions are made, how decisions are taken, and how diverse teams come together to build something impactful.

That said, there were a few challenges we faced during the course of the project. Notably:

  1. Delays in Pull Request Reviews and Approvals: At times, there were significant delays in getting pull requests reviewed and approved. While we understand that maintainers are often volunteering their time, quicker feedback would have helped us iterate and improve more efficiently.

  2. Lack of Comprehensive Documentation: The codebase lacked sufficient documentation, which made onboarding and initial understanding difficult, especially for first-time contributors. Clearer explanations of the architecture, data flow, and setup instructions would greatly improve accessibility for new contributors.

Despite these challenges, I thoroughly enjoyed the experience and would highly recommend open-source contribution to anyone looking to grow as a developer. It helped me develop both technical and collaborative skills, and I am grateful to have been a part of this initiative. I look forward to staying involved in the community and contributing further in the future.

1 Like
17

I kind of understand your point, but what if I am dumb and I don’t have experience of Frappe or X software, how do I get work done in 9 hours of office and push something meaningful out every day ? I do not know if this is really called “corporate work” and it sounds very far from “enjoy and understand what you do” to me.

If experience is everything, figuring out everything on your own is invaluable and that apparently comes under experience (on a very high prominence), PR’s are not everything. Software engineering is far bigger than PR’s (and you know better than me). Progress, course work, deadliness all sounds good and shiny but there are more valuable things than that in my understanding. When the goal is PR’s, the goal is only quantity of PR’s not the quality. (I saw some intern writing frappe dependencies as FOSS United apps architecture).

To share my experience, when I interned, @Harsh_Tandiya never really had the time to look after me or look at my work other than reviews. And I never even bothered to ask him for help mostly because he was also new and he had the majority of responsibility as he was by-code owner of the platform. I’d find stuff in broken frappe docs and internet and figure it somehow on my own. Agreed, that I wasn’t able to make 1 PR every day (like you proposed later on after you joined). But, I understand frappe (maybe a tad-bit and not all around) but I do understand on how to make my own way through it.

Maybe, I don’t know what your understanding and definition of “Software Engineering” is and maybe mine is different, thats why this clash in understanding/personal views. Maybe, I’m harsh with wordings or rude or whatever, but I’m just trying to be straight forward and don’t have any ill-intentions. Because, its bad to end up learning wrong things.

Anyways, I conveyed my point mostly. And my question stays (don’t really need to bother answering maybe), what even is the goal of this whole program. PR’s, progress, metrics and analysis of work or learning, understanding code/software, experiencing breaking and fixing things on their own.

You can see by the feedbacks that they’ve started chasing metrics more than enjoying and tinkering with code and software and finding meaning in what they do. Maybe its not too intriguing, but I would never quantize my learning as metric.

18

That sentence was immediately followed up by the following

which are excellent goals/metrics to follow, in my opinion. They’re not chasing silly metrics like one-PR-per-day or N-number-of-issues per week. If the goal is to improve performance, having some sort of clear metric/endpoint ensures that progress happens towards that goal. We don’t need to hit that goal, but the goal still helps ensure that we can course correct if and when we veer dramatically off-course!

We are again veering dramatically off course for this forum topic - the topic is about FOSS and Software Engineering education - as part of a college curriculum. 9-hours-of-work and pushing something everyday is far beyond the scope of the topic.

But to address your comment, “enjoy and understand what you do” is all well and good when there are no incentives tied to the work. If there are incentives e.g. a regular salary, course credits, there is always going to be an expectation of “get things done”.

I’m not talking about becoming a corporate slave and pushing meaningless code day-in-and-day-out but there is a lot of meaningful commentary on the internet on the value of building momentum, in work or in other aspects of life, and the way to build momentum is to do things. I’ve said this before, and I’ll say this again - even today, there are small, simple, silly issues in the FOSS United codebase that can be addressed in small PRs every single day.

The point of 1-PR-every-day in this context was again to build momentum. And that was after we had identified a well-scoped issue that could be broken down into multiple smaller PRs so that progress could be made every day. I think I mentioned this to you when we had originally discussed it but please correct me if I’m wrong.

Thank you very much for this question.

^ is the goal of the program, mentioned in the very first paragraph of the first post on this topic. Get students to work on FOSS projects. Indian FOSS projects specifically because we’re able to facilitate conversation with the mentors/maintainers, and it reduces timezone friction for the students and project maintainers.

We’ve met that goal

1 Like