FrOSCon is a conference about Free Software and Open Source in Sankt-Augustin near Bonn, Germany. Here I want to give my impressions from the visit this year. (btw, it was the 10th FrOSCon this year)
Day 1
It took about 15 mins to get in, so I missed the start of the first talk. In the conference bag was the usual set of conference program, coffee voucher and flyers from sponsors. I was really suprised to see so much “culture” talks in the program, usually such talks will be hold on Agile conferences. I joined directly the first talk from sipgate about OpenSpace and OpenFriday.
Thank God it’s Open Friday
Corinna Baldauf, Scrum Master from sipgate, talked about their experience over last 4 years @sipgate with Agile methods and problems, discussions with C-level about trusting the employees.
One very interesting idea was to have a slack time between the sprint changes(NDS day = Nach Dem Sprint Tag): team members can do anything they want (solving issues, maintenance, research etc). Well, it wasn’t really transparent and didn’t really solve the issues with “technical dept”.
After some further tries they implemented a regular “Open Friday” with the Open Space format. This turned to be a very good idea and was later implemented for entire sipgate company. So, its more or less like a “Fed-Ex” day, but on the regular base. This helped to get transparency, provided an efficient format and enabled knowledge transfer, innovation across the entire company. Very interesting experience:)
How To Get Your Patch Accepted
Lorna Mitchell talked about review criteria, quality of submitted patches and in total provided a good view from code maintainer or reviewer perspective.
Key messages:
- “3 ingredients: code, words, perspective”
- Invent acceptance criteria for your patches
- Avoid any commented code in your codebase
- Follow the contribution guides and create own for your projects
- Ask yourself how you can break your code as the end-user will do it for sure
- Create tests
- Follow coding standards
- Provide good commit messages: they will help to understand the reasons for particilar code after some years
- Learn to use your tools (e.g. git): squashing of commits etc
- No applogies in submissions: either the code is good or it needs to be better
- Use automated builds/testing
- Rebase/merge your code on the latest master and fix the issues
- A pull/merge request is a first step in the conversation about your change
- Describe the use-cases and intention in your pull/merge requests
- Cover the question “why a maintainer should merge this?”
- Be prepared to invest time for improvement of your pull/merge requests
- Do code reviews of foreign code to learn and improve your coding style and quality
- Provide documentation for your code, comments in the code as well
- Reject the contributions youself if code is bad or something is missing
Minix 3
Andrew Tanenbaum talked about the usual problems with operating systems and software and gived an overview over Minix evolution in the last years. Minix is a free open-source operating system designed to be highly reliable(more reliable than Windows and even Linux).
From my POV Minix isn’t a research/example OS only anymore, like it was in the past. It runs the NetBSD packages, can be installed on the Boards like BeagleBone and might be very interesting for embedded development. There are interesting ideas like live OS upgrade without affecting the running processes. Such thing can’t really be realized the same way on the other operating systems.
Go Away Or I Will Replace You With A Very Little Shell Script
Kristian Köhntopp gives some of his views on DevOps, culture, development of culture. There were quite interesting examples from his professional experience. Thoughts with real examples in direction like “You don’t want to have issues in production? Then break you production reguary by youself! Do your tests in production!” are very interesting, espessially when you see something like “Budgeting downtime”
Day 2
The second day started exactly like the first one: with a huge queue to get coffee.
How to Motivate Your Developers
Anna Filina talked about developers motivation. She tried to take different perspectives (e.g. from developer and management) and to provide ideas to management how to reach the higher motivation and cover (even possible unknown) needs and wishes.
This also included different views on experts and beginners and even different motivation points were covered.
Beginning of the End or End of the Beginning?
maddog gived a keynote. There were a lots of interesting (insider) stories from the history of computers and his view on the future. Very interesting and funny:)
Der Linux Netzwerk Stack
Florian Westphal explained the architecture of network stack inside of Linux kernel and gived a good overview over the flow of bits&bytes there. The backgrounds and reasons were quite interesting, now I know who is ksoftirqd and why support of fast cards (e.g. 10Gbit) is a bit complicated.
Docker in Produktion
Last FrOSCon talk and the room was quite full. Its clear - its a topic like Docker.
Sebastian Mancke from Tarent shared the experience on Docker in production. They built the full automation chain for deployment with Docker:
- every change must to be packaged to the image
- this image gets tested
- and shipped to production
In the same time, all used solutions must be as simple and small as possible. No unneeded complexity!
For me it was the first Docker talk at all, which covered my questions and expectation on the productive usage, requirements and architecture. The guys wrote their own orchestrator gig, which covers “missing” features from fig/docker-compose, but aims to be compatible with fig/docker-compose YAML files. The mix and implementation of environment parameters for images is just great!
Other stuff
