I love Free Software day 2020 (German version below) Simply saying thank you - something we often forget in the day to day flood of tasks, accountabilities and responsibilities. Today the Free Software Foundation Europe is celebrating the “I love free software day” to express gratitude to those who are underpinning a lot of today’s businesses by developing Free and Open Source Software. Much as last year we would like to join the celebration and say thank you to the developers backing the software that makes our platform perform well on a daily basis.
Knapp 450 Stunden - die Zeit die es bräuchte, um alle Vorträge der FOSDEM 2020 die letztes Wochenende in Brüssel stattfand, anzuschauen. Von Legal and Policy, über Container und Security, Datenbanken, Netzwerk, Java, Go, Quantum Computing, Continuous Integration bis hin zu Embedded/ Automobile und Open Source Design reichte die Themenbreite. Dieses Jahr hat die FOSDEM gezeigt, dass nicht nur technische Themen für den Bereich Open Source entscheidend sind. Im Community and Ethics Main Track hat Danese Cooper gezeigt, welche Schritte notwendig sind, um auf kommunaler Ebene für die Adaption von Freier und Open Source Software zu sorgen.
Imagine the following situation: You would like to drive a change in the gh#innersource repository. You already have commit access. Typically you’d make the change, post it as a pull request and wait until someone has time to review and approve. (German version below) There is another way that we typically choose when the change is relatively uncontroversial: In the original pull request, indicate that the model for the change is a lazy consensus model where the pull request is kept open for a defined number of days - and if nobody objects, it will get merged after this period is passed.
(German translation below) … for asking questions In addition to tracking decisions in the making issues are being used for those who would like to ask InnerSource related questions. Asking them in the issue tracker instead of in 1-on-1 settings has three advantages: There’s more than one knowledgeable individual that can answer the question. Others who may have the same question later on (or even now, in case they are afraid to ask the question) see that there are others who openly learn something new.
Imagine the following situation: You’ve seen a certain discussion pop up multiple times and would like to draw the lessons learned together - but in a way that leaves space for others to provide their knowledge and experience. One setup that turned out to be effective for this type of situation in gh#innersource was the following workflow: Open an issue, post the problem statement at the very top and invite people to discuss steps towards a solution of the stated problem.
For the introduction of InnerSource at Europace we relied on gathering a group of people interested in the topic. While most of the discussion is designed to be remote-first with all issues being discussed in an asynchronous way we also set up an internal monthly InnerSource meetup. That meeting is open to each and everyone for attending. Meeting dates, location, and agenda is posted in advance: In a GitHub issue dedicated to the particular meeting in the gh#innersource project, On the Slack channel with the same name as the GitHub project (slack#innersource), As a calendar invite to those attending regularly and to those who participated the last time.
Starting the InnerSource initiative we needed a place to collect documentation as well as a place for operational coordination. We decided to dogfood suggested tooling and created a GitHub repository. Going forward, I will refer to it as gh#innersource here. Before publicly discussing gh#innersource as a project, a certain amount of base documentation was being created. As a baseline this meant creating an initial README.md. This document serves as an entry point for newcomers to the project.
Trusted committers are the ones responsible not only for software development but also for mentoring, for pulling new people into the project, for helping and supporting downstream users with the goal of adding them to the Trusted Committer team. But how do you go about adding new Trusted Committers? The way this works in the InnerSource project at Europace is that for people showing obvious commitment, one of the existing Trusted Committers will step forward, nominating them as a potential new Trusted Committer - giving a short explanation of why.
Leading by example - how we introduced InnerSource and coordinated adoption of InnerSource best practices inside of Europace. In Adopting InnerSource we described how we were following what Vijay Gurbani (Vijay K. Gurbani, Anita Garvert, and James D. Herbsleb, “Managing a Corporate Open Source SoftwareAsset,” Communications of the ACM 53, no. 2 (2010) 155–159.) describes as an infrastructure based model of introducing InnerSource to a new organisation. What does that mean?
Wettervorhersage Brüssel: Heiter bis sonnig, erst ab Wochenende Abkühlung, Schneeregen, Wind - passend zur FOSDEM, die jährlich Anfang Februar an der ULB stattfindet. Wie jedes Jahr verteilen sich mehrere hundert Vorträge auf ein Wochenende. Dazu unzählige Möglichkeiten, sich einerseits direkt vor Ort mit Aktiven aus der Open Source Szene zu treffen, aber auch in Form von Meetups, social Events, Pre- und Post-Konferenzen. Ich persönlich habe mich dieses Jahr auf die Themen Legal, Policy sowie Community mit einem kleinen Abstecher zu Freunden im HPC, Big Data and Data Science Dev Room konzentriert.
tl;dr Check if the power of Hystrix ( or any other tool ) fits your requirements. If it feels some kind of weird - it probably is. the players Hystrix and its friends ( like Eureka & Co. ) are part of the shiny new world of ‘companies hand out their great tools for free!’. And indeed they are - not only because they are production tested real world tools but also due to the effort the community puts into documentation and community management - thanks :) On the other hand one always should keep in mind: Those tools are not only made by but as well made for that very company.
67% – laut der 2016 von Blackduck Software und North Bridge veröffentlichen „Future of Open Source“-Umfrage ist dies der Prozentsatz der befragten Unternehmen, die ihre Mitarbeiter ermutigen sich an Open-Source-Projekten aktiv zu beteiligen. Ein Drittel der befragten Unternehmen beschäftigen Mitarbeiter, die ihre Arbeitszeit ausschließlich in Open-Source-Projekte investieren. Die Gründe sich an OSS-Projekten zu beteiligen sind vielfältig. Konkrete Zahlen nennt die bereits angesprochene Umfrage: 67% beteiligen sich, um Bugs und Probleme zu beheben.