And I can continue.

Yeah, okay. Thanks. Thanks a lot for the nice presentation actually before.

I mean, I'm taking a bit of a different perspective.

So I will present you the life cycle of Gamma Pi and Gamma Pi, as I would call it, like a community driven software package.

I deliberately put a bit of a provocative title saying nothing works.

So I think I really like this diagram that we've seen in the previous talk, like of autonomy and alignment. And probably I think with our project, we're maybe starting in the lower left and trying to make up our way to the upper right.

Yeah, the subtitle is really like lessons learned from leading and maintaining the open source project, Gamma Pi.

Okay, so why nothing works.

When developing software in general, I think we are typically confronted with the state, nothing works most of the time.

This means like typically we spend more time to debug code than to write it.

This means we fix broken CI tests. This means we find that the sign-to-hoices that we have made in the past do not scale or do not work as expected.

We find that our software has missing features.

For example, we find that the performance is not good enough, etc, etc.

So I think what we have to accept somehow is really that the software is never in 100% final state, but rather undergoes a process of constant improvement.

And also as we can never avoid bugs or missing features, changing API, design mistakes, etc, completely.

So I think like the second best thing we can do is somehow set up a working process for the software that actually tolerates for these imperfections and these mistakes.

Okay, so just very quickly, what is Gamma Pi?

Gamma Pi is an open source Python package for GammaRay astronomy.

And the basic idea is that it provides functionality to do a high level analysis of GammaRay data, somehow based on common data formats.

So this could include, for example, data from the health experiment, from the future CTA observatory, from Fermi data,

or possibly even then came 3-net data, like new team like data.

And starting from these common data formats, then you can do like a high level science analysis.

So you can create images of the sky, you can create spectra, you can create light curves.

And all of this is done just by relying on the scientific Python stacks or relying on packages like AstroPy, NumPy and SciPy.

And it is also an open developer package.

And it was started like in 2012, basically just as a set of Python scripts developed for the Haskell Arctic Plane survey by Christoph Dein and myself.

And now, but by now, we approximately have like eight years of experience in developing and maintaining this package.

And just as a side note, we probably have three within the package since then, like three times.

Just a few more numbers. So in total, we have like 120 forks.

And over the time, we have seen roughly 60 contributors to the package.

And in total, there are like 13,000 comments.

And so, I mean, compared to, for example, the effort in SKA, this is a rather small project, but also like for community driven project,

I think it's also not a large one, but also not a very, very small one.

And you can just see like a very quick timeline of how the development here happened in Python, starting in 2012.

And then we've seen a number of minor releases, but also really like increasing activity over time and also increasing number of contributors.

So these are roughly 10 contributors per week. And this is now our average and also in lines of code.

But all this like growing activity and growing lines of code forced us a little bit to rethink our working process and adapt somehow to these changes.

And I think what is important to understand somehow is really the aspect of the community driven thing or the open development.

So it's not really like a classical linear developer and user relationship or like a company customer relationship.

Because I would say like in general, there's no strict structural boundary between, let's say, developer and the user.

So in the sense, users develop some code provided for others.

And it's really like about this exchange.

In a sense, you could say also that users know really the best what they need and somehow deliberate for the benefit of the community.

And I think one could probably also describe somehow like as a self-organizing structure, partly including some quality to ensure and somehow based on crowd intelligence.

And I think it's probably best understood also maybe like in a Web 2.0 context.

So, for example, if you compare it, let's say to YouTube or Wikipedia, where really there's no strict boundary between the content creator and the consumer.

So this is really like the setting we are working with.

And now if you take a look at these classical software development life cycles, and we've already heard about this from Eager, so I'm not going to explain this in detail.

But of course, there's, for example, something like a waterfall model of self-software development, which typically applies, for example, where the company delivers a product to customers, or really developers implement software for users.

So if you start to fill requirements, you'll write those up in a requirements document, then you have a design phase where then you get somehow in the software architecture.