 Okay. Hello. How are you? Good. My name is Alex and I have been coming to Foshtem for the past 10 years, every single year. And this is my first time doing a lightning talk. This is also my first time when I'm traveling together with a team so far I've been alone. And this is also the first time our team is having a project stand here at the conference. And all of this is pretty cool. And I want to tell you the colourful history of Kiviti CMS and what we do, what we stand for. And I want to tell you that we are turning 10 years old this week. We are celebrating here at Foshtem, so it's all good. So, but first, what is test case management? When you do software testing, quality assurance, you need to keep a lot of information around. You need information about which version of your software was tested, on what kind of environment, which build, what kind of test cases were executed, which ones were not executed, what was the testing result. And at the end, all of this information boils down to, should I ship this version to the customer or no? If you are a test manager, maybe a test lead, you will go to the system, take a look at the test results, figure out how happy you are with the current state of affairs in testing, and make the decision, ship or don't ship. So, in the commercial world, there are quite a few options for such systems. They are relatively popular. There are some that look very nice, others that look rather ugly. There are plugins for JIRA, there are standalone systems, desktop systems and web systems and so on. In the open source world, we don't have a lot of options. Initially, there was a test link. It's very old projects, many of you might have heard it. It is still a little bit active. They released about one version a year or something like that. Then after a test link came to Stopia, another project from Mozilla, again open source, working in the same domain space. They lasted for a couple of years, and it kind of disappears. Unfortunately, Mozilla doesn't use the Stopia anymore. They don't support it. Although there are some commits made to the repository. So, not really active. In 2009, I was working at Red Hat, starting my career as a software tester. They decided, well, we don't like the current systems that are available in the open source world. Let's build another one. This is how it was born. This is the first version that was released 10 years ago. This is how our history starts. This thing continues development for a while privately. And as we know, everything Red Hat touches becomes open source. So, this is no exception. In late November 2014, the source code was pushed to GitHub. This is a nice thing by itself. Unfortunately, the way this was done was kind of indicating the direction where upstream was going. We have one single commit, no prior history, a bunch of files put together. We have no idea what they are, how they work. Turns out there is a lot of source code which was not used. There were a lot of functions which were not used. There were duplicate functions copied around different modules which were not in use. The test suite wasn't working. So, all of that in the initial commit. So, anyway, the GitHub history tells you that development continues for a while. From what I can tell mostly from people who are on the original team of the upstream system. And then slowly in the next year, in 2015, kind of dies away. So, at that time I was consulting for a small startup company and we wanted to use such systems. So, the obvious choice is whatever is open source that is available on GitHub, let's take it, make a deployment internally, figure out if it doesn't work, we'll fix it. So, this is what we do. And we immediately start running into problems. So, first upstream is using a very, very old version of Django that is full with security problems with bugs. We want to upgrade immediately. That's not possible because you cannot just jump from Django 1.6 to 2.0. So, you have to go through every single minor version and fix a lot of stuff that is failing in between to actually be able to upgrade. Upstream is using MySQL. We are using Postgres and you will say, well, it's an ORM-based system, but it's not. It's ORM-based and we had a lot of hard-coded SQL statements in the source code which work only on MySQL. They didn't work on Postgres. So, we had to fix. Upstream was using Vagrant for deployment. We were using Docker. So, we had to build our own Docker images as well. So, fix, fix, fix. And we started sending pull requests upstream. Some of them got merged, but most of them didn't. And the funny thing is my first ever pull request to the upstream repository was made almost three years ago and it is still open to this day. That is about changing the bug tracker system in this tooling. So, upstream integrates, they have hard-coded bugzilla.redhead.com as their bug tracking system and you cannot use anything else. That's still open. So, what we do, we do a lot of internal development. We do fixes. We start deploying internally. And, you know, we kind of start liking the system. And at the same time I left the startup company and I decided I will continue to work on this alone because I like it. And I think, you know, it can be a nice project. It can be revived. So, the obvious thing of choice to do when upstream is that is to create a fork. And this is what I did. So, I took the fork which we had internally in the startup company. It was in a private repository. So, I took it externally to my personal GitHub account, continued development. And during that time I was able to fix the entire test suite, clean all the deprecation warnings, remove tons of stuff that we don't need. We have removed, just for reference, about 20,000 lines of code and the system continues to work pretty much with the same functionality in the same way that it used to do before. So, you have a function that works with your data. And then you have another function that is called from the front end via Ajax. And it does the same thing. It just copies the code. It doesn't use the other function. And then you have the same action somewhere else in the system. It just copies the same thing over and over again. So, we fix all of these things. We started building Docker images and started pushing them publicly for everybody on Docker Hub. And surprise, surprise, people actually started to download them and to use them. They started reporting bugs and started contributing and so on. And I was starting to realize that all of this to handle is too much for a single person. So, I asked my friend Yanis from Mozilla. Yanis, tell me what should I do if I want this to continue? And he tells me, well, if you want this project to have any, like, chance of surviving and becoming a little bit more popular, it needs to be independent from yourself. You have to create a separate GitHub organization. It needs to have a website so people can follow the progress if they're interested and so on and so forth. And most importantly, you need to have a team that will help you with all of these things. So, I decided to follow the advice of my friend and started building the website. And the option was build it myself or ask somebody else to do it for me. And I chose the second option. So, I found three young developers and I told them, listen, I want this simple website to be built. I will tell you how to do it. I will teach you all the technical skills that you need to have. But you need to commit on GitHub. You need to help me. And if you like it, you can continue further to work on the project. And they built the website. They learned a lot of stuff. From the three of them, only one was left on the team. This is Ivo, this guy here. He is very young. And the reason he's not here today is because he cannot travel abroad. He's too young. So, after that, he decided to stay around in the project, learn Python, learn Django, started fixing a lot of pilot errors. And until now he's fixed more than 3,000 pilot errors that we had in the source code alone. Which is quite impressive for somebody who didn't know anything less than one year ago. Then we had Anton, who joined a little bit later. And he's a little bit more experienced developer. But again, he learned Python, he learned Django. Started working on the backend stuff with me. Now he's working on a lot of the front-end stuff. Changing how all the pages look and feel in the system. We're migrating to another library for the user interface, which is more modern, nicer to use. And this is mostly done by himself alone. So I just give some directions and I do the initial proof of concept for some page and then leave everything to them to do. And during all this time, I've been trying to make the project more popular. I've been trying to recruit other people to help us be part of the core team. And we hit a snack with a lot of them. So we've got people who wanted to join the team and then didn't feel motivated enough to stay around and to contribute. We had people who didn't want to learn all the skills that they were missing, although we provided all the information for them. So we had to kick them out, unfortunately. And right around this time, I started to realize that it is too much for me to handle both the people's side and the technical side. And that is why we have Renny, who is our team coach. And these two guys, they are over here. So applause for them. Thank you very much for helping me. So we've got a team and we need a community. And the way to build a community is to let it form itself. So we enable the community to form around the project. People ask for translations. We find a suitable translation system for them to document how to use this. They start contributing. And we've got French, Slovenian and German translations 100% contributed by the community. We don't speak these languages. Next, we document how to set up your development environment, how to deploy the docker images, how to configure the project. Because it's Django, it's straightforward, but it turns out a lot of people are not familiar with Django and it's hard for them. Once you document all of these steps and make it easy for them, they start contributing. And last but not least, you have to travel and you try to spread the word and tell people about your project. And we've done quite a lot of traveling last year, to be honest. Way too much traveling. And the nice thing is we meet other people who work in the same domain space. So we are not alone. Two of these guys are Daniel from Germany and Dimitri from Belarus. And they both work on related open source projects. So they work on system test portal and report portal. And the three of us together today and tomorrow are hosting the open source test management stand here at FOSTEM. So come and say hi, learn something that maybe you don't know about testing, how it's done, how you can collect all the results in these various systems, what they can do, and so on. And last year has been very successful for us. We started with pretty much zero external contributors. And by the end of the year, we have had contributions from some relatively big companies and organizations, small contributions from big names. We have also had bigger contributions towards the end of the year from somewhere from Brazil. I don't really know where that is. Some states, which I haven't heard before, have a good contribution from a person. He didn't ask any questions, just send a pull request. It was perfect. We could merge it immediately. And we have decided, OK, the community starts to form around the project. So let's set up like a bigger goal for the project. We want to be the best in this field and we want to reorganize to change how testing is done in an organization. We have posted a lot of requests for comments on GitHub, a lot of ideas, some screenshots, what can be done, what is possible technically, what is possible on the organization level. There are a lot of people who gave us feedback. If you do software testing, quality assurance, feel free to give us feedback to tell us that we are not doing something right or that we are idiots or maybe that you like it, hopefully. And the last thing is we celebrate 10 years. If you can figure out what this thing means, do the actions and come by the open source test management stand. We have a present for you. Thank you very much. I think we have only one minute for questions. Two minutes? OK, cool. Yeah, it's a puzzle, yeah. If you can solve it. Yeah, but if they tell everybody this. Well, doesn't matter. Puzzle. No, you have to think about it. So thank you very much for listening to me. Thank you, Alex.