GSOC totals

August 30 ended the Google Summer of Code, in which we took part for the second time. In general, the result is decent - the majority of students confirmed that they were not chosen in vain. But there were mistakes, which will be discussed in this article. To summarize the results of the GSOC, mentors were interviewed - the very people on whose shoulders everything kept for the past six months. Details under the cut.



Recall that in the spring five projects were selected:

1. GUI-based FTP client - creating an FTP client with a graphical interface, correcting errors in the protocol implementation and adding support for some FTP protocol commands, supporting file uploading, logging of action history.
')
2. Torrent client - creating (writing wrappers for libraries of one of the cross-platform clients) console version of the client that will download (decode a file, get a list of peers, establish a connection with peers), distribute, process messages from the tracker and show statistics.

3. Port PolarSSL - port of the library into an assembler language, including writing of cryptographic algorithms and support for the TLS protocol.

4. CPUID_tool - update the program so that it can identify processors released in the last 9 years, as well as determine cache sizes and supported functions.

5. C layer - writing wrappers in the C language for libraries box_lib, proc_lib, libini, libio, http, rasterworks, kmenu, libimg, libgfx, archive, buf2d, xml, libcrash.

Detailed information about the projects is presented in the table.

Project	Programming language	Result	Mentor (s)
GUI-based FTP client	Assembler (FASM)	pass	ashmew2
Torrent client	Assembler (FASM), wrappers for C libraries	pass	hidnplayr Pathoswithin dunkaist (unofficially)
Port polarssl	C -> Assembler (FASM)	pass	hidnplayr Pathoswithin
CPUID tool	Assembler (FASM)	fail	Wildwest
C layer for KolibriOS	C, wrappers for libraries on Assembler (FASM)	pass	Albom

All mentors were requested to comment on the projects.

Ashmew2 review:

I was a mentor in an FTPC project.
The current status of the project is a graphical interface and the main functions are implemented.
I achieved the following things when leading a student:
- explain to him that you need to frequently do updates and write messages on the forum;
- (very important) to make him take responsibility for the project and consider it as his product;
- to be only a beacon, pointing the way and not trying to feed the student with a spoon;
- give enough alternative options and challenge its approach (suggest only if necessary);
- weekly discussions (2 times a week, based on the student’s free time).
In the end, for me it was a good experience of leadership and teaching someone how to work on a project.
The best thing from my point of view is that even after GSoC, the student is still improving FTPC and I will continue to run it for as long as he wishes, because this is the beauty of open source!

Mentors of two projects Pathoswithin and hidnplayr refused to answer, which characterizes them not with the best hand. I had to interview an informal dunkaist mentor about the progress of the torrent client project.

Dunkaist recall:

Strictly speaking, I was not an official mentor on this project, since I recently changed jobs and objectively could not devote enough time to GSoC. The student was engaged in another person. However, when Utsav decided to refine my torrent client workpiece (at that time, in fact, the torrent file parser and the basic structures and constants), I agreed to help him and answer questions as much as possible. At first they were, but rather quickly ceased. After some time, I myself became interested in the current state of affairs, and it did not please me. The commits were also rare and insignificant. The absence of questions with such activity was alarming, although the student was repeatedly made to understand that any questions can and should be asked at least on the forum, even if you don’t be embarrassed at the IRC. I attributed the unimpressive successes to the intermediate certification to a long-term entry into the project. At about two-thirds of the program, I singled out the evening in order to properly understand the current state of affairs. And I found that some of my advice and essential architectural solutions were ignored. That, generally speaking, is not bad in the presence of a reasonable alternative, which, however, I did not find. On August 24, after the development stage was over, the code from the repository was not even collected. Later, the assembly was fixed and the student posted screenshots with a working case, which I never earned. If Utsav continues to develop this project, I’m ready to code it and fix the architecture to save the developer, otherwise I’ll continue from the place where I finished it once. Wait and see.

Wildwest recall:

Three students claimed to work on the project, but, by coincidence, I had to choose a student from the USA. I did not think that everything in the US is so bad with education. The selected student turned out to be rather weak and lazy, trying to postpone the difficult parts of the project until later. She also constantly lied that she did almost everything, and after a week or two it turned out that almost everything was done and only started to do the same for her, and in response to comments about poor work, even Hamila. Basically she was engaged in copy-paste with the subsequent small code modification. As a result, by the middle of summer about a quarter of the project was done, with complete lack of understanding of both the overall picture and the details of the processor identification process. Before the midterm, I warned other mentors that the chances of implementing new algorithms are zero. After receiving undeserved money on the initiative of the administrator Pathoswithin, the pace of work has generally fallen, she began to correct the bugs she introduced and improve the interface instead of writing new functions. By the first decade of August, less than half of the project was done, and somewhere around this time it turned out that the student had not fully read the Intel documentation and did not know that it was necessary to write new code for function 04H. When I explained this to her, she refused and instead of writing the code, she offered to write a document on how to do it (sic!). After that, she began to do a fairly easy task - writing an exception. I made two attempts, in both cases the program crashed when launched on new processors ... The project's file became a natural result - well, you can’t put a pass for an unfinished program that crashes upon launch. But the story continued ... More on this below in the error section.

Albom's feedback:

For an operating system, most of which is written in assembler, this language is like no other suitable for developing system software. This is due to the convenience of calling system functions, the simplicity of organizing data structures, the ability to efficiently use computer resources, the beauty of the solutions used and, finally, with a certain old-school fun. However, programming in assembler requires more work than in high-level language. It so happened that for KolibriOS a decent number of applications was written in C. On the other hand, over the past few years libraries of functions have been implemented in assembly language that simplify the lives of programmers. The idea of ​​the C_Layer project was to implement the interface of these libraries for programs written in C. This, in turn, would unify some of the code (i.e., ideally minimize the use of their “bikes” by programmers), simplify and speed up the process development, and reduce the number of bugs in the new code. C_Layer was supposed to ensure the ubiquitous use of standard GUI elements that are implemented in the box_lib library. And this is the "editbox", and "checkboxes" ... In general, almost everything you need. Also in the plans were interfaces to libraries for working with graphics (libimg, libgfx, buf2d, rasterworks), files (libini, libio, archive, xml), network (http). Student punk_joker, who worked on the project, according to the mentor (Albom), fulfilled the minimum necessary for successful delivery, although the expectations were much higher. So what was done? Interfaces are written in assembly and C languages ​​for the main libraries, examples in C and “makefiles” for assembling interfaces and examples. What was missing was documentation and tests. But the small size of the examples will allow programmers to thoroughly study them and understand the principles of using interfaces. As for the organization of the student’s work, everything was also ambiguous. Punk_joker lost a lot of time, sorting things out on his own, without asking for help from a mentor and ignoring his recommendations. As a result, a lot of work had to be done in the last days of GSoC. However, today the project is at a normal level (as for the student’s work), work on it does not stop and, I hope, will develop and benefit the KolibriOS programmer community and open source software in general.

About errors

Dunkaist opinion:

Over the past few years I have happened to be both a student and a mentor, so I know firsthand the problems of both sides. And the most important of them, in my opinion, is incomprehension.

It all starts with an application for participation, in which the student discovers his unfamiliarity with such an entity as the architecture of the project. Most applications are like two drops of water and boil down to the implementation of 10% of the target, then another 10% and so gradually to 100%. About 80/20 rule few have heard. For a student, misunderstanding of the architecture of the project results in an illiterate plan, according to which it is impossible to work and, as a result, loss of guidelines. For a mentor, this is a headache with grading if some code is written, but the critical mass for a working prototype is not gained.

The second thing that students often do not understand is the demands and expectations from the community. For many students, $ 5,500 before paying taxes for three months is a lot of money, and therefore they mistakenly take GSoC as a job. Moreover, in its most primitive form: I give you money - you give me a code. Things like dialogue with project participants or open discussion are vanishingly rare. Mentors seem to be bosses who can’t be asked stupid questions, and the community is a bunch of angry testers who are just waiting for a reason to laugh at the novice’s mistakes. For a student, such a misunderstanding causes prolonged entry into the project and loss of time; for the mentor - additional obstacles in identifying problems and trying to help.

Not everything goes smoothly with the mentors themselves. There is an opinion that the task of a mentor is to answer student questions. I am personally convinced that this is not the case and that the real task of the mentor is to organize the process. The process by which a student will write a code. This is a daily task that takes time and needs to be kept in mind. Answering the student's questions, the mentor only clears his conscience: I gave him everything he asked for. In practice, the student is young and inexperienced and may not ask the right questions, make a mistake in choosing the direction of development. For a student, this is a dead end in architecture that has arisen after weeks of work, deadlines and the resulting fail. For the community - another abandoned project, minus one potential developer.

In summary, we are all human and make mistakes. Fortunately, there are not so many of them, and the project has an understanding and desire to work on the bugs.

Wildwest Opinion:

I believe that not only professional, but also human qualities of the process participants are important. And therefore, a very careful selection of all GSOC participants — administrators, mentors, and students — is needed. The trend of this year was the presence of scams among both students and administrators in our Open Source project. And both types need only money. Fun-students, in every way they pull with the implementation of projects, they react to any persuasion by a small activity purely for show. They would even be satisfied with $ 500 per month of community bonding, and if they were also given money at the midterm, then they generally become impudent and stop working, which is what happened to my student. Moreover, when she was flooded, she began to play surprise, writing in support of the GSOC and on the forum about what a difficult life she had and that she gained credits after she was accepted into the GSOC. Another unpleasant news of this summer was Pathoswithin, whose actions, in my opinion, indicate that he is a swindler. He volunteered to become an administrator, although he was in the project for about six months, then he began to write that he would take part of the money for himself, then it became clear that this part would be quite large. At the same time, he practically did nothing and made a mistake at the midterm, when he decided to fill out reviews for all the mentors and missed my scumbag student. When he became aware of his mistake, he began to shift the blame on me, to create various scandals on the forum and in the chat room, in order to divert attention from his plans to assign GSOC money.

punk_joker

Wildwest's opinion should not be considered absolutely groundless or the ultimate truth. This is his personal view of the problem. The opinion of other members of the community is also not the same, and there are both supporters supporting the Wildwest and its opponents. So the conclusion is not as clear as it may seem.