Isabel Drost-Fromm

In a world where we stand on the shoulders of giants, where we build systems that are increasingly interconnected, supply chain security is becoming more and more important. As Free and Open Source projects, we believe that we can lead the way for the industry in terms of processes, best practices and technology patterns. In this open panel, we want to discuss the importance of security in Free and Open Source Software projects. We want to encourage participants of FOSS Backstage to share their questions and insights about topics like supply chain security, security processes, vulnerability disclosure, bug bounties and more.

Other people: Thomas Fricke Gregor "Little Detritus" Bransky

Our founders Isabel Drost-Fromm and Stefan Rudnitzki will look back on five years of FOSS Backstage!

Other people: Stefan Rudnitzki

A virus caused a lot of teams to move to a remote first setting in the matter of a few days. Too often the result was teams emulating office settings with remote video conferencing. In this talk we will look closer at how Open Source projects succeed in handling highly distributed teams. We will look at patterns that can be applied inside of companies to make not only remote work more efficient. As a side effect we will see how adopting Open Source collaboration patterns on the inside will lower the barrier to contribute to regular, public Open Source projects.

Software is eating the world, Open Source is what's driving innovation. In this interactive fishbowl session I would like to work with the audience to explore the advantages of being actively involved in the open source projects that you use at work, which arguments work in convincing your employer that contributing patches upstream makes a lot of sense business-wise. I would also like to explore the legal, process and people challenges companies face when setting out to increase their open source involvement.

Instead of a talk where one human speaks and others are listening the goal with this session is to involve the audience in exploring what it means to transform a business from merely using open source projects in their day to day work to actually being involved upstream. How to identify the kinds of contributions that make sense for upstream projects? What are the legal, process and people challenges with becoming more active in the open source world? Which arguments worked for you in convincing your manager to give you time to work on a patch? What properties should you watch out for when trying to identify projects that are welcoming patches from downstream users? Open Source as a movement is at an important point today: While adoption is raising to ever higher numbers, there are projects that are suffering from a lack of development power. To quote an article on Open Source sustainability from The Apache Software Foundation published: https://blogs.apache.org/foundation/entry/the-apache-way-to-sustainable - "At Apache, more users means more success since they are our future contributors." In this session I would like to explore what it takes to make that conversion from user to contributor.

Your project's code base is rock solid, you are rolling releases early and often, your test suite is comprehensive and running regularly, your code is well performing without any glitches. Everything is in place that defines a successful open source project - or isn't it?

This talk tries to highlight some of the key questions software developers will quickly be faced with when dealing with open source: In addition to coding skills, topics like people management, naming, trademark enforcement, licensing, patents, pr and more become topics to deal with.

After years of using open source projects, running my own projects, founding meetups and conferences, watching others thrive or fail I believe that coding skills alone aren't sufficient to turn a "private play ground code base" into an open source project that other's can rely on.

Inspired by 140 characters of truth published here: https://twitter.com/janl/status/... the talk will focus on what topics that are usually not taught as part of programming courses will cross your way when dealing with open source - either as a user or as a contributor:

• People: Is the project willing and able to attract more contributors? Is it able to survive if the leader looses interest or time to continue contributing? How does the project deal with requests coming from the user base? How easy is it for users to get their issues fixed?

• Trademarks: Why should you care about trademarks from the beginning? How do you deal with others infringing on your trademarks?

• Copyright: Why should you care, exactly which license you choose?

• PR: While writing release notes is common practice and composing changelogs is pretty easy, the resulting documents are hard to grok for editors and won't get you on the front page of any magazine. Nor will they help you get visibility on common social media systems that might be key in informing your users about recent releases.

While being excellent at all topics isn't vital from the start, answers to governance questions decide what a project looks like a few years from it's start.

It's easy as pie: before checking in, your test suite should always be green. Or should it? What if your tests are all green but you forgot to check one important edge case? What if your underlying system environment lets you down, but only under rare conditions that you didn't cover in your tests?

This talk introduces randomised testing as used by projects like Apache Lucene and Elasticsearch based on the Carrotsearch Randomised Testing framework. It has helped uncover (and ultimately fix) a huge number of bugs not only in these project’s source code, but also in the JVM itself which those projects rely on.

Writing unit and integration tests can be tricky: assumptions about your code may not always be true as any number of "this should never happen" log entries in production systems show. When implementing a system that will be integrated in all sorts of expected, unexpected, and outright weird ways by downstream users, testing all possible code paths, configurations and deployment environments gets complicated.

With the Carrotsearch Randomised Testing framework, projects like Apache Lucene and Elasticsearch have introduced a new level to their unit and integration tests. Input values are no longer statically pre-defined but are generated based on developer defined constraints, meaning The test suite is no longer re-run with a static set of input data each time. Instead, every continuous integration run adds to the search space covered. Though generated at random, tests are still reproducible as all configurations are based on specific test seeds that can be used to re-run the test with the exact same configuration.

Add to this randomising the runtime environment by executing tests with various JVM versions and configurations,and you are bound to find cases where your application runs into limitations and bugs in the JVM.

This talk introduces randomised testing as a concept, shows examples of how the Carrotsearch Randomised Testing framework helps with making your test cases more interesting, and provides some insight into how randomising your execution environment can help save downstream users from surprises. All without putting too much strain on your continuous integration resources.