Submission 7603 (Learning Experience paper)

[AntonioCerone]

Exploring the Foundations of Open Source Software Development: A University Course Review

Abstract Open source software has emerged as a fundamental cornerstone of modern software development, transforming the way software is created, distributed, and maintained. The collaborative nature of open source projects has given rise to a robust structure and set of practices that developers worldwide adhere to. This shift towards a more organized and professional approach to OSS has paved the way for the creation of university courses tailored to educate students and aspiring developers about the intricacies of open source software. This paper presents a detailed review of one such university course, focusing on the author's personal journey and contributions throughout the duration of the course. By sharing their experiences, insights, and challenges, the author offers a firsthand account of the course's curriculum, highlighting the development tools, collaborative platforms, and real-world projects explored and contributed during the program. Ultimately, this paper underscores the significance of open source software courses in empowering developers and students to become more confident and aware contributors to the ever-expanding realm of open source development. OpenCERT_2023_paper_7603.pdf

[twasserman]

I will review this paper. Tony Wasserman

[sdptn]

I am happy to review this one too

[AntonioCerone]

sdptn, could you please state your identity? Thank you.

[sdptn]

sorry :-) Stefano De Paoli

[Donatella-Persico]

I will review this paper. Donatella Persico

[LuigiLaura]

I will review this paper. Luigi Laura

[Stamelos]

I will review this paper. Ioannis Stamelos

[neversi]

Dear reviewers,

I am Abdarrakhman, the author of the submitted paper. I wanted to take a moment to express my sincere gratitude for your time and effort in reviewing my work.

I look forward to any feedback you may provide and to the opportunity to address any questions or concerns you may have regarding the paper.

Best regards, Abdarrakhman Akhmetgali

[AntonioCerone]

REVIEWERS for this paper:

• Nicola Capuano
• Stefano De Paoli
• Luigi Laura
• Andreas Meiszner
• Alexander Mikroyannidis
• Donatella Persico
• Ioannis Stamelos
• Anthony Wasserman

[sdptn]

Here are some comments on this work:

This is an interesting first-hand account of participation to an Open Source project as part of a University course. Some of the details related to the process of becoming part of the community are detailed. What is interesting is that there are not very many works relating to how external participants can take steps to become part of an established OS community and contribute to software.

I have seen similar papers in previous edition of OpenCert, and like before I think there is little reflection on concepts and theory and much instead is just practical details. I could imagine several concepts which could be used to provide a stronger argument to this paper. For example the concept of Legitimate Peripheral Participation which addresses how novices slowly become established members of a communty (e.g. https://www.taylorfrancis.com/chapters/edit/10.4324/9781315014500-4/legitimate-peripheral-participation-communities-practice-jean-lave-etienne-wenger). Moreover, it would have been nice to learn more about the structure of the community of the chosen project. Open source projects may have organisational structures (some more defined, some less) which tend to be described in websites etc. Knowing some more details about this would make it easier to understand how an external participants could then become a member and contribute.

In the conclusion the focus seem to shift toward education and bringing OSS into academic curriculum. It would be interesting to elaborate this idea better also in the earlier part of the paper, and perhaps in the conclusion also connect this aspect to some academic literature on e.g. learning. Again concepts from communities of practice or peripheral learning may be interesting here.

While the paper can be read, I think a further check to the language would be beneficial. For example there are sentences where the same word is repeated many times, which then make these sentences convoluted, see e.g. this one in section 1.2 ". In my case, I have chosen the project related to the WebRTC [3] project that I have used in my previous projects for real time video streaming.". The word project is repeated three times, and makes the sentence rather odd.

[Donatella-Persico]

First of all, I would like to congratulate with the author of this contribution for its clarity and quality. I appreciated, in particular, the effort made by the author to highlight the problems faced and the added value of participating in a course like this. I also noted the minor linguistic issues highlighted by the previous reviewer, although I believe they do not hinder understanding. I think the paper could be enhanced by adding some reflections concerning how the course educational approach could be improved. For example, how about the unresolved issues mentioned in section 6.1, 6.2 ? Can the author envisage a teaching approach that could lead to better learning and less frustration? Does the author believe that team work would have enhanced learning and attenuated frustration?

[twasserman]

I always look at papers to see what others can learn and apply from them. In this case, I had a hard time doing that. For me, you focused far too much on the details of what you did as a developer contributing to an existing open source project.

Even though you were trying to write a review of the course, you didn't say very much about the topics that were presented as part of the "theoretical" part of the course, and your material about the practical parts were almost completely about your work. I didn't get a good sense of what was in the instructor's syllabus for the course.

For me, the paper seems more like a final course report to be submitted to the instructor. You haven't explained the "big picture" of the course or the various types of technical and non-technical projects that other students are following.

I apologize for being late in submitting these comments to you, but I was traveling last week, and didn't have the opportunity to review the paper until now.

[andreasmeiszner]

Good day, As commented by other reviewers, the nature of this paper is more a reflective one, showing how learning and progression occurred. What is less developed in this paper is how it advances the existing knowledge on this type of learning approach. If this were to be brought out the learning approach would need to be looked at through the lens of the literature and what can be learnt from this case compared to what is already known. Best, Andreas

[LuigiLaura]

Hi, I find this paper very interesting (indeed, this is why I chose this one over the others, it is more in my chords :-), but I agree with what other reviewers have pointed out: this paper primarily focuses on reflection and the process of learning and growth. To address this, it would be beneficial to analyze the learning approach in the context of existing literature and identify what new insights can be gained from this case study in comparison to what is already known. Best, Luigi

[Stamelos]

Following the observations of other reviewers, I agree that this is an experience report, more than a research paper. Providing information about an interesting experience is always a good idea, provided that there is some link to previous similar reports or (better) more generic relevant papers. The current paper IMHO may be improved in the following ways:

• Provide more quantitative information, e.g. how much time and effort was spent on the project in total and for each described task separately.
• Compare the experience reported with other similar reports. I recall that in last year's OPENCERT edition there was at least one paper of this kind from the same University. The author might provide a direct comparison with that student's report and pinpoint differences and similarities, eventually arriving at some conclusions or ideas/proposals for improving the learning experience.
• Produce a thorough literature review on this type of learning setting, i.e. OSS project participation for software engineers. If this is done, the author may place his own experience in the big picture, again identifying some potentially interesting aspects.

As a conclusion, this paper may draw the conclusion that learning in such way is beneficial, but doesn't provide really useful information for current and future adopters.

[pbreuer]

Since I don't in the end have a paper I can review, I'll add some comments here too, as I was interested to find insights on/about "exploring" and "foundations". Unfortunately, as all have remarked, I was disappointed. It's just a "I did this and that" report, followed by some generalities that are unconnected, but doubtless look like the right thing to say! Rather than take issue, I'll add advice here o how to do it right.

First of all, pure editing: DO NOT USE OR INTRODUCE ACRONYMS OR JARGON. If you don't, you won't have anything to explain, and you will not annoy a reader when you don't even do that. A reader can at understand 7 new things in reading a paper, going on three, and every acronym you insist they learn to parse that sentence is one less space for what you really want them to know.

Second, what DO you want the reader to come away with? You have to think of a message. Plainly you wrote "what happened" and hoped to come up with a message in the end, but I didn't see one, so no message, which kind of kills things as far as story telling goes (all papers are stories, if they are any good), but it's easily repaired by thinking of one. And then you don't leave it to the end, but put it in at the beginning, and spend the rest of the paper saying how your experience and understanding relates to that message. Here, I think the message is that someone who didn't really know a lot about coding finds it all very difficult and has no idea how it is more or less difficult than any other kind of coding, if it is, so who knows what gives and what could one possibly expect the author to say! How does this compare with SCRUM? SCRAM? Waterfall? Agile? Who knows! Not me, not the author. Did you try and find out about other workflows? No? Why not? I really mean that! What the reader needs is the WHY, not the what. You didn't try to figure out what's different here because a student has enough to do just getting through the task, but did you perhaps look up the names of other workflow methodologies in software engineering, just to know what they are? The WHY not the what is always the interesting part. Here's a starting URL on that: https://en.wikipedia.org/wiki/Scrum_(software_development) which will tell you that you are undertaking a month long "sprint" in a "scrum" development model where the tasks to be done have been divided up between members of the group to attack singly (allocated to you to have a go at). Look up the other software development models there and see if you notice the relations, and COMMENT on whether you recognize your experiences, and in what guise. Within different OS projects different group architectures will dictate the kind of development model being followed.

Let me also help you by telling you what the "right" conclusion should be at your level :-) Here is what the problems of a first-time or even more senior open source contributer SHOULD be. The difference between first-time and senior is only that the senior knows that these are the problems, and the junior does not, but the problems are the same:

1) figuring out where in the existing code the functionality you want to fix or add is or should be put (MUST ask the people who know). Where to even look!

2) How to do it at an abstract level (open a socket, configure it, blah). If you don't already know by virtue of the expertise you are bringing to the party, ASK.

3) how to make sure that your code does not leak resources (close sockets at the right time, release memory, ...). You need to get your code checked for such errors, and/or ASK. What common mistakes are made by every new contributer and how to avoid them? Ask.

4) how to be sure there are no unexpected interactions of your code with other parts of the code. Again, ask! What does other code expect of yours to do and not do.

5) how to know what you can depend on and not depend on in the coding environment - i.e. what invariants exist, for example, whether your code may be interrupted by an exception or not, and how many threads of execution there are that may potentially access yours and what it may do. Where is this documented and explained? ASK!

6) what coding style and naming conventions to use. Those should be in the documentation, to which you will be directed when you ask.

The very best you can hope for is that somebody has written an O'Reilly book on the project. Have they?

Your actual conclusion ... is not acceptable as it is because it makes general claims like "By actively participating in open- source projects, students can build a portfolio of work that showcases their skills and contributions. Employers value concrete evidence of an applicant’s abilities," for which you have gathered and presented no evidence and therefore cannot and must not state. REMOVE all of that. For all you know only the hopeless students are known to employers as trying their hand at o/s projects, because they can't get a "real job". Do not make claims without careful and complete referential and evidential support, ever (in an academic environment - in politics it is fine!). It is essential that you remove all such unsupported claims. I cannot emphasize that enough. Ask yourself of every sentence, has what you say been justified by evidence, reference or logic? If not, out and away with it.

I'll append the file of notes I made as I read through. These are not criticisms but marks of things to correct in your text so that the reader gets the impression you really want them to get from it. My misunderstandings are the points where you should think how to alter the text to help me (and other readers) to avoid my mistake or unwanted reaction in reading it. There might also be ideas for you there - remember that we want the WHY, not the WHAT.

7603-rev.notes.txt