The Python Podcast.__init__

Share on social media:

[00:00:13] Unknown:

Hello, and welcome to podcast.init,   the podcast about Python and the people who make it great.   When you're ready to launch your next app or you want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With 200 gigabit private networking, scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up.   And for your tasks that need fast computation, such as training machine learning models or running your CI pipelines, they just launched dedicated CPU instances.   In addition to that, they just launched a new data center in Toronto, and they've got 1 opening in Mumbai at the end of 2019.  

Go to python podcast dotcom/linode,   that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of the show.   And you can visit the site at python podcast.com   to subscribe to the show, sign up for the mailing list, read the show notes, and get in touch. And if you have any questions, comments, or suggestions, I'd love to hear them.   And to help other people find the show, please leave a review on iTunes and tell your friends and coworkers.   Your host as usual is Tobias Macy. And today, I'm interviewing Pablo Ruiz Muthkidd about Tyga, a project management platform for agile developers and designers and project managers who want a beautiful tool that makes work truly enjoyable.  

So, Pablo, can you start by introducing yourself? Sure. So my name is, Pablo.  

[00:01:37] Unknown:

In Matriascha's terms, that will be, that's Europe,   Spain, and Madrid. Let's say, academic background wise, it's physics and computer science. Hobby wise, that would be literature,   role playing games, and traditional archery. Activism wise, civil rights, free and open source software, of course, transversal feminism, and promotion of critical thinking and science in society. In terms of professional career, I'm currently CEO of, Kaleidos.   It's acquired. These are IT company in Spain that has, you know, various innovation and incubation schemes   that actually gave birth to Tiger, where I'm co CEO with,   professional investor and friend, Ricky Posner. And do you remember how you first got introduced to Python? I do. I do. We have to go back in time to   1997.  

So I was studying my master's degree my master's degree in physics.   I was involved in running student association computers. The type of service that would give, you know, students an email account,   that we have to access through Telnet and use Pine and all that, it was it was so much fun. And I had to choose between Perl and Python as a scripting language, you know, to, to do some system tasks. And,   you know, somehow, I don't know, perhaps it was the functional influence that Biden had or the fact it was also very science friendly or, I don't know, perhaps I I love the tutorial. I don't know the Monty Python's puns. So I chose Python. And at the time, it was not an easy choice, you know, because Perl was, predominant.   But, it turned out that I got rewarded almost immediately because, you know, over the next few years, I found that decision to be helping me achieve some great stuff. You know, whether it was hacking,   software hacking, some open documentation project that I started. I needed a template in system. Computational physics also benefit   benefited from from that decision. Game development using Blender actually sent money to the to into 2, 002 for when when Blender needed to, they did this crowdfunding,   when there was no crowdfunding. They they had this to make sure they could release the the source code   as open source. So I used Python   1.4.  

That's my first Python, release. Yeah. So over 20 years now. Yeah. I think I started in the 2.3 or 2.4  

[00:03:50] Unknown:

time range. So a little while after you, but, it's definitely great to see how far it's come along in the years. Yeah. And so you said that   at Kaleidos,   you have   spun out the Taiga project   as   product from that group. So can you start by explaining a bit about what the Taiga platform is and the overall reason for building it? Yeah. So you you you know, Tiger is an agile project management platform.  

[00:04:16] Unknown:

And, and I think   4 4 or 5 years ago, we had 2 reasons to build it. We would do it again.   1, there was no truly open source   agile project management platform back then. You you you had,   and you still have, Redmine   or Track, which is actually written in Python, but there was no truly open source agile project management platform. These 2 2 platforms were great management platforms, but they were not really agile. They were open source but not agile,   not for the agile project. And 2, we had these obsessions about   being able to develop   an open source   platform   for end users that was beautiful, you know, was   slick. Like, a nice example of, you know, open source software that is also super user friendly. And I think we succeed in both to have these, open source plus agile   and, a slick tool. So that was that was the reason. Yeah. And I had previous experience  

[00:05:15] Unknown:

running Redmine,   1 of the first jobs that I worked at in technology,   And I've also come across Track because it's used in a few different projects in the Python ecosystem. But both of them are fairly   obtuse and difficult to get set up and get to a usable state if you don't know intimately what you're doing. So I definitely appreciated when I came across Taiga the fact that you have a lot of built in,   sort of instruction   and fairly well put together   onboarding for being able to get an instance deployed   and be able to have it in a usable format for being able to do some project management   versus what existed before then. So definitely   good work on that front, and it was nice when I found Taiga that   it was something that, as I said, was a little easier to get up and running because before then,   a lot of the existing open source options or self hosted options were either written in PHP, which is fine. But as you said, they weren't agile oriented, or the few Python options were a little bit more convoluted and difficult to get set up. Yeah. I mean, we we were great fans of Track and Redline. They're great platforms. It's true that we wanted a Python based 1.  



[00:06:30] Unknown:

Track is Python based, but it was   clearly focused on very different audience or, or use cases. So,   you know, it's that those those times where you you you just sit down and say, we will have to build it ourselves. You know?   Now you can do it as a as a copycat,   or you can definitely   pursue a new concept or, or, you know, be original and and new and also try to make some points.   And I think we,   we are, in that sense, we are sort of genuine,   if you can say that. And,   and and yeah. And we and we also try to make a a business model out of it. Perhaps we can talk about that later. But, at the core, it's, it's a  

[00:07:13] Unknown:

truly open source platform. And as you pointed out, there have been project management tools, both open source and proprietary   for, basically, as long as we've had well, as long as we've had teams, but in terms of software offerings, as long as we've had computers that were able to,   you know, handle the presentation logic.   And so I'm curious if you can   give a bit of context in terms of how Taiga fits into that overall ecosystem, both now  

[00:07:42] Unknown:

and what that landscape looked like at the time when you first started working on Taiga. Yeah. Yeah. As you say, there's there's they've been, you know, probably my platforms for a long time.   I think there are a lot of them. You know? I think they're second only to   ecommerce platforms. You know?   It's it is for Tiger,   it it it's it's,   above all,   it is a massively fragmented market. It's not just that there are a lot, but also it's a fragmented market, you know, except for a few notable exceptions.   So when you you go to this crowded market   where   there's lots of options,   you need to make sure that you you have some   meaning, you know, some reason to exist. Otherwise, you're just yet another   platform. There are many.  

And the vast majority   are closed source, of course.   So we we said, okay, what might   make   Tiger   worth existing and worth developing?   So we can start with Agile at its core,   not just scrum   and kanban, but making sure we follow the agile manifesto, the agile principles.   That is that was very important.   Open source is 1,   important asset for Tiger. A lot of people will go for Tiger because it's open source. A lot of people will just use it because they like it. But a lot of people will, they have this filter. I have this filter. And it's like, if if it's not open source, I won't use it. Period. So you can download and run it behind your firewall, so have it on premise. We also decided that we wanted to make sure that it was meant for   multidisciplinary   teams. This is very important for us.  

A lot of platforms   will just focus on   1 or 2 type of users   and will   alienate all the users. We wanted   to make sure that multidisciplinary   teams could work together and that Tiger was not meant just for software development, but for any type of project.   And then   a nice UI.   These days,   it's true, and it was true 4 or 5 years ago. Some people will just use software because it's prettier   than the competition. So with agile open source, multidisciplinary   teams, not just for software development, which is, for some reason, like,   every product management platform is   tries to solve that use case, and it has some issues. I think that there's a fundamental problem there. And an s UI   that,  

[00:10:14] Unknown:

that makes a compelling case for Taig, I think. And as you pointed out, the market for project management is quite fragmented where they're dividing lines along the   sort of style of project management. So whether it's agile or water flow or or waterfall   or whether it's focused on a particular type of team. So it could be for sales teams or it could be for software teams or as you said, it might be for cross functional teams   or there might be requirements in terms of the,   sort of reporting capabilities.   And so I'm wondering what it is about the overall problem domain of project management that makes it so   complex to build   a tool for,   and what it is that   leads so many people to try and solve the problem over again, and why there isn't, as much standardization   or consensus on 1 given tool unless it's something that is so flexible that you might as well just write your own tool from scratch to get the actual workflow that you need. So,  

[00:11:16] Unknown:

I see that's a 2 part question. Let me answer the second part first. I think people are just obsessed with, building tools as the the recipe for success. You know? So they will they will feel that,   given the right tool, team dynamics, processes, and everything, which is flourish. And, instead of it's like the same obsession with frameworks. Like, instead of developing the end product,   people sometimes say, okay, I'll just build first the framework. And then 1 end result of the framework will be this this product that I had in mind. So I think our people get stuck in, in developing project management instead of, you know, going and and just doing the project. But as for the first part, you know, these challenges,   the unique challenges about project management. Well, I I personally firmly believe that any project management methodology   is better than having none. Just have 1. That would be my my main, you know, piece of advice. But I also believe that agile is statistically much, much better suited for for the vast majority of projects. You know, having said that, and in my experience having managed many, many, many projects throughout, you know, all these, years,   I   I would say   that   project management is more about the team than the project itself.  

So that is that is really the challenge. And that means how the team works together, you know, how expectations   and trust are managed.   It means that you should be able to predict the future as much as you can.   You need to understand the value of frequent introspection   because you want to improve. And when I say I when I say a team, and and you you used that term earlier, I include all stakeholders, you know, including the customer slash user. Otherwise, you may you might end up with,   dysfunctional team. You know, when people complain about a project   they're working on, I think they very quickly point to stuff that is very much related to team dynamics. Not the project itself, you know, not the end goal, but team dynamics. So, you know, be careful with egos,   toxic behavior,   the problematic absence of I'm sorry, you know, at least in Western culture, all those need to be addressed. But also,   you know, solidarity, team commitment,   being a professional, which combines, you know, honesty,   generosity, and redlines, you know, saying no. So you have all these   these,   challenges, and you go and you have to build a product management platform. And you know this. And you know you don't want to stay in the way of the team. And at the same time, you want to reinforce   these, you know, virtuous behaviors. Which in the case of Tiger is quite ironic. Since you know that the first ideal principles say something like individuals and interactions   over processes and tools. And TIGA is a tool. So how can TIGA, as a tool, lobby in favor of individuals and interactions? That is our unique challenge.  

And, all the all the platforms, you know, the domains don't have. But here we have a tool that despises tools, you or at least that considers itself to be potentially misleading. And this is people have to understand,   you are writing something that would say it shouldn't exist. You know? Thankfully, the principle says over. It doesn't say against. It doesn't say,   how is it? Individual's interactions interactions against. It just says over. So it's a matter of prevalence. It's not binary. So we had to be very careful, you know, to carefully deal with, Tiger's role within the team dynamics. And this has made a lot of people love Tiger, but also have made our people reject Tiger. This little session with the first principle, agile principle, is problematic for some people. I mean, they won't say it out loud. They they won't admit it. But some people really want to be agile,   but through processes and tools. And Taiga has an issue with that, you know. We don't want to overcharge that,  

[00:14:58] Unknown:

part of the, sentence. And so can you talk now about how Taiga itself is actually implemented   and some of the main features that it provides   to enable effective project management and agile workflows?  

[00:15:13] Unknown:

Yeah. So, well, it, Taiga is, is fundamentally a a RESTful API.   That that is what it is.   You know, underlying technology is, it's Python, of course.   Then you get Django, Django risk framework, PostgreSQL,   RabbitMQ for async notification,   and a nice Angular JS front end using CoffeeScript. That is, you know, technology that we're using. The design of that has evolved a little bit over time, but nothing really dramatic. You know, we have a work in progress   and some evolution to newer versions of Angular JS.   But what's changed is mostly workaround performance,   and that means query optimization, database publishing, things like that.  

Yeah. You know, at Tiger, we're fans of sustainable development, and it seems   it seems we did a great job at the beginning ex except for the front end, perhaps. We haven't had many instances of these infamous   we can't do that, Tiger wasn't meant   to do it, you know. Quite on the contrary. Now   the   you want me to cover the the features?   I mean, Tiger's main entity is a is a project,   and a project has a team of people.   And you can be part of many projects through different teams.   Now I probably can enjoy scrum,   the scrum module framework, or Kanban,   or both if you know what you're doing.  

Some people do activate   both modules.   So that's right. You could have sprints,   And in parallel, you can make use of Camden, campaigns, sorry, for those same user stories.   So with scrum, you get your backlog,   rent out charts, sprints,   which actually feature a kanban style workflow for user storage tasks.   We call it the sprint, task board. Then kanban is your typical Kanban with columns,   WIP limit, etcetera. We also have a ticketing system   called, issues,   which is very powerful and is to use. We have,   Epic user stories module too that can contain local product user stories or external projects user stories useful for, you know, bird's view management. We have a nice Wiki module for documentation.   We have a straightforward   video conference system. And so every epic user story, every user story, task, or issue enjoys   assignments, watchers, comments, tags,   block status,   due date,   attachments,   workflows. You know? User stories in particular can be estimated.  

So you can customize nearly everything. We also have super flexible filters and search functionality   and,   desktop in app and email notifications. So a typical workflow would first have to decide, you know,   whether scrum or kanban works best. You have committed capacity, and   and you,   you need certain predictability   over what's coming next. You normally tend to choose scrum. Right?   If you don't have that or you prefer to focus instead   of detecting bottlenecks along the user story life cycle, you most probably prefer Kanban, which is apparently simpler,   but, I I believe requires a much more mature team.  

That's my opinion. You create your new tiger project. You select your product template.   You can change later that decision if you want. That's okay. You can start with scrum and then,   move on to Kanban. That's that's okay.   You can go with default values for everything   and start creating your stuff,   or you can go to admin, which is super user friendly. I think what that's 1 of the key I think I I forgot to mention that is 1 of the key differentiators for Tiger in this crowded market. Super easy admin. And, you can go there and make Tiger look the way you want. And then you typically invite all the team members. You assign roles, and that's it. You know, you can start working right away. And 1 of the things that I liked too as I was playing around with it before this conversation is the ability to import directly from other tools such as Trello or GitHub so that if you have already been  

[00:19:09] Unknown:

getting started, but you didn't go to the full effort of getting a certain project management tool set up, but you are already using 1 of these lightweight options, you   can transition your existing state without having to start from scratch and go through the process of manually entering all of those things all over again. Yeah. I think we made the decision  

[00:19:28] Unknown:

of helping people do the transition, I think, 2 years 2 years ago because we felt   that, to be clear, you know,   projects   tend to last, you know, months or even years. And so for a team, it might be, you know, too much to just start from scratch,   using Tiger, even if they love Tiger.   So we have these importing,   mechanisms.   Also, you we have exporting mechanisms, not back to those,   platforms that you mentioned, but for any other Tiger instance. You know, we we we feel that your data is yours. So you could export any project, on 1 Tiger instance and and import it back into another 1. But this idea of integration, I think it's,  

[00:20:11] Unknown:

comes comes across, a lot in Tiger. Yeah. And I think the fact that you broke out the back end from the front end and that the primary communication is just over those rest APIs   was a good choice because 1, it makes it so that all of those rest APIs are first class concerns within the back end and within the data model so that it makes it simpler for being able to integrate with other tools, but also it means that it,   1, you can host your front end as static assets on something like s 3 or a CDN separately from deploying the application.   And it also makes it easier if somebody wants to write their own UI on top of those APIs   without necessarily   having to take everything that you've already done or if they have opinions or also for your own purposes, if you want to be able to evolve the front end   separately from the application so that you can continue to use what's already been written. But then once you have something that's fully functional as a replacement, you just have to switch it over without having to go through all the process of   decoupling the UI elements from the back end repo. Yeah. Actually, we have  

[00:21:17] Unknown:

the you know, a lot of people will develop   API centric,   and it will never really get used out of their own   platform. It's just   an architecture   choice and with this this potential that you that you just described.   But we had   an amazing example of   what you can achieve with that. Because a year ago or a year and a half ago,   we got this email out of the blue from this guy called Alex   from Germany, from this company called TechFunder.   And the email   said something like,   hey,   I just,   finished developing   this native Tiger app for Android,   iOS, and Windows.  

What do you want me to do? You know, what we do with this? And   lo and behold, there was all this work   that had been developed by this team   completely   in the dark. We didn't know about this. And just through the API documentation,   they were able to develop a fully functional TIGA native app. It's not the TIGA official app. We cannot call that the TIGA official app, but it's it's amazing, you know, that that someone could do that.   That that means it's the API is well documented, of course,   but also   the the potential is there. And and   in this case, it was tangible. So and a a lot of people would use Tiger's API   for a lot of very weird integrations. We have some very nice examples going on because there's no 1 tool to rule them all. You know, fortunately, I believe,   you know, people have ecosystems, you know, have many tools. And to be able to be part of that ecosystem   and be, you know, easily integratable, I think is,   is is great. And and it's easier when your front end is using the same API. It's not just an afterthought. It's this this other API developed, you know, later, and it's used just for integrations. It is actually the core   product's API. We have out of the box integrations for, you know, major tools. We have webhooks. We have live CSV exports. You know, we can do you can do a lot of stuff without using the API. But in the end, you know you can rely on the API for anything you want. You can actually do more stuff using the API than using the current front end. And I think that that approach is definitely valuable, particularly for project management tool, because as you said, there is no  

[00:23:49] Unknown:

1 service that is going to rule the entirety of somebody's workflow for project management or product development because, you know, the actual development work is going to be happening on GitHub or GitLab or whatever your source control platform of choice happens to be. So unless you want to incorporate all that functionality into Tyga,   then you need to be able to have some way of communicating between those platforms or,   you know, maybe you need to be able to integrate with your sales CRM, and we wanna be able to track status of the overall sales funnel in your project management tool.   Again, you know, unless you want to eventually end up reinventing all of the different services somebody's going to need to be able to get their work done, you need to be able to have some sort of ecosystem option where other people can plug in the functionality that they want   and not have to have it be dictated ahead of time by the people driving the product road map for their product management tool. Yeah. Well, I have a strong strong opinions on that. I mean, about how all the companies  

[00:24:48] Unknown:

do address that   ecosystem   scenario. But let's move on, and perhaps,   later we we can discuss some examples because it's it's happening. You know? There's people   focusing on 1 particular use case or or a niche platform,   while others   want to, make sure they cover every single thing the company needs or organization needs. You know? And   sometimes it's just patching together too too many too much stuff, you know, too many tools, and it just feels, well, Frankenstein. And so that's a good opportunity to talk about your ideas of how you approach the overall  

[00:25:22] Unknown:

usability and user experience of people using Taiga and how you balance that against the push for adding in every feature that somebody might want to the point where Taiga becomes so flexible that it's ultimately unusable. And in order to actually get something functional, you're essentially just rebuilding all of the project logic from scratch. So I don't know what your thoughts or approaches are in terms of maintaining that balance.  

[00:25:46] Unknown:

Well, that's it's impossible.   It's impossible to maintain that balance.   And and this is our little nightmare, actually,   you know, because we want to appeal to almost any agile oriented team out there,   whether it's software development,   what they do, or just planning a wedding. And we got 100 and 100 of feature requests around this very topic,   You know, use   flexibility customization.   You know, most of these feature requests go   around flexibility and customization.   And   because they want to make Tiger more and more central to the project and team dynamics.   In essence, they want more tool   and less individuals and interactions.  

So it's it is amazing   how people   are attracted to Tiger by its simplicity   and streamlined   nature.   And then they come to us and ask this very super trivial tiny feature that will make Tygab so perfect. And when we listen to these people, because we listen, we have regular video calls with users and all that, most of the time, they need more control over what people are doing. They need more workflow triggers.   They need more time monitoring.   They need more permission based action. So now we could develop all of that. You know, sometimes, really, these features are simply to add, but we have to review our agenda as a platform. How much team conversation do we want to take place within our borders? I can tell you a lot of platforms will say   everything.  

We want everything to happen here with me. Come here. It's everything here, but we don't want that. So what we do is we study   the underlying problem that made that issue to appear, you know, and in the first place, and we dissect   that problem. And we see if there is a Tiger way to solve the problem and still, you know, keep Tiger focused. You know, sometimes the solution is to leave some options as advanced configuration.   So it's just not default. Sometimes the, the solution is to make Tiger   just more intuitive in those specific problematic   fields, so that those teams don't have to be super creative with Tiger. Sometimes we concede. You know, sometimes we say, okay. You're right. You know? Sometimes we just end up saying no. We and we I mean, you have to be able to say no with with some elegance and, you know,   there's reasons and you have to explain, but sometimes you have to say no. So it's really challenging   to keep this balance, you know, but you learn a lot   about how people use your product   and their own challenges.  

And it's amazing how they believe and that it's related to why people keep developing, you know, product management platforms, how they believe that it is the tool that will sort out all those problems. But unfortunately,   if we said yes to everything   we got asked, we would end up being, I don't know,   something really horrific. And some tools have ended up like that. Just saying, okay, you want that. I don't want to lose you as a customer or as a user. We will give you that. And then it's just advanced options   or more configuration   or and all that streamlined process just gets lost. And all that simplicity   gets lost. And so sometimes you have to say, you like Tiger because it's this way. I'm going to say no, and it's it's better for you, you know. I I I need to explain this to, you know, patronize patronizing, you know, with yours. That's forbidden. But,   so we try to find the underlying problem and give a tiger compliant solution to that. But it is, it is, is it is a nightmare. Super problematic.  



[00:29:18] Unknown:

Yeah. And playing into that, again, is the fact that you do have these APIs so that for at least certain cases where somebody wants to embed a certain workflow logic or restrictions or capabilities into the platform itself,   they are still able to create some bolt on integration that will provide what they need without   integrated for everybody whoever uses Tyga, and so they can solve some of their own problems that way. And so I'm sure that there is opportunity either for you or for third party vendors to be able to provide those integration services for people who do want to add those workflow customizations.  

[00:29:57] Unknown:

Yes. That's there's actually   1 very common example of that, and that's reporting. And, you know, reporting needs   are very, very different across, you know, the whole world. And,   different teams need different reporting   capabilities. So we decided that target would have some reporting, but we'll just say, if you want more than this, there are, niche   tools   that you create reporting.   Just use the API as a as a source, and you can play with that. And you can, you know, just enjoy all these capabilities for these reporting platforms and keep Tiger just for project management.   So and we know there are many private Tiger instances around the world behind big organization firewalls,   very big ones. And the main reason that we have those Tiger instances, you know, deployed,   even if we don't we cannot reach them, is because the the API   and the how easy it is to integrate a tag with other corporate, you know, services or whatever. So, yeah, I think it's easier to say no to,   some features when you can say, but you have the API or when you can say, but we have this flexibility   here, you know, or we can say, you know, it's open source. So I think other other platforms cannot say that. We we can do that. So we probably minimize   the, the pain   that is that exists when you say no repeatedly, you know, to your to to your users. And 1 of the challenges and tensions that arises  

[00:31:25] Unknown:

when dealing with any open source project is the idea of governance   and road map.   And so I'm wondering what your approach is on that front to ensure that you do have the ability to maintain the   ideology and direction of the project while still allowing for community contribution and engagement,   and also what your approach is as far as licensing for Taiga to  

[00:31:49] Unknown:

ensure its future success as an open source project? Yeah. So, I mean, Taiga is a a is a is a piece of software. And I think in terms of,   responsibility   for maintaining, you know, this project   As as any   engineering   endeavor, I think it's you should focus on technical debt, you know, sustainable development   and user validation. So we make sure that Talaga addresses those. Because very often, products have a great start, and then somehow, they just turn into a horrible mess. You know? And, nobody   knows how or when it happened. And I think 1 of the reasons is because,   teams,   this responsibility   gets diluted somehow. But I think,   at Tiger, we make sure that we have the whole team,   protecting   and owning   the, the end result of the product.  

And we, we don't. We do incremental development,   and we have, I think, many of   the best practices   in place.   So,   the community plays a a big role. We would like it to to play a bigger 1, and we're working on that. But for instance,   we have   22 languages   translated into Tiger or Tiger translated to 22 languages, just thanks to the community,   which is amazing how, it's a a lot of people will will use tiger because it feels native to them. They will say, oh, I want in Hebrew, you know, or I want in Farsi or Korean.   So you have to be able to deal with all those contributions,   pull requests, and all that in a in a sustainable manner. You have to protect because some if you say no to,   to a feature request by a random user, why would you say yes to any contribution that comes from the community? You know, you have to follow the same strict principles, and we have a contribution policy in place.  

So so yeah. And what was the second part, sorry, or the question?  

[00:33:49] Unknown:

The rest of it was just asking about your approach to licensing and how that plays into your vision for sustainability for the project? Tiger  

[00:33:57] Unknown:

is licensed   under the AGPL   version 3. So that's Apero GPL,   which is uncommon.   And not as uncommon as people believe.   I think last,   forced them in Brussels, there was this   talk about someone that said people believe that a Ferroglpl is not that successful,   and they're wrong. And so we decided that we, as a as a as a platform that provides a service over the web, but it's the API of the front end. You know, when you create such product in 2014,   2015,   you had to say, what do you you know, in terms of licensing, you can go for the Tipple PPL version 3 or version 2, or you can go for a mid based or, you know, BSD license, you know, more free software or open source. But when you have a service   and you want to make sure that service stays free and open, the obvious choice has to be AGPL. And I think we   that's   it it it is, it's it's part of our agenda. You know? Why AGPL? Well, people that know AGPL know that it's a very,   it's opinionated licensing scheme. You know? It's about what the type of of Internet that we want to build. We want to build services that are basically black boxes, services that are typically black boxes, or do you want to provide a service but also provide all the freedom that came with that? So at the moment, anyone that would like to fork, contribute,   provide any Tiger service themselves can do so, provided their users can access their source code. And in terms of contributions   and, you know, community,   yeah, help and everything,   it hasn't been an issue. So and for us, as a small company, I think it actually protects our interest much more than other not so,   service oriented licenses.  



[00:35:43] Unknown:

And so in terms of the overall   engagement   of an individual and a team with Tyga when they're going through a product life cycle, you talked a bit about the   overall success and adherence to whatever the sort of project management tenets are within a given team, if it's something that should be driven by a project manager as a role or if it's something that should be handled   distributed   across the team and just what you have found to be best I think, as I say, you know, product management, I think it's more about team management.  

[00:36:24] Unknown:

So, I think as I say, you know, product management, I think it's more about team management. So if you you need to make sure you have, you know, the right talent, you have motivated people. There's 1 thing call it I called,   working team agreement.   The I I I I have managed many other engineering projects, not just Tiger. And the key   is the whole team's involvement.   You know? And a nice, as I said, working,   a nice working team agreement. The working team agreement, I found to be great because it is a document that states what is considered acceptable   under what circumstances. We also,   I think teams should also have this definition of pride   concept. And once you make it that explicit for your project and everyone applies to it, private life cycles tend to be, you know, never ending creative process. That is very difficult to implement if there's 1 person that gets all the responsibility.  

I think you you know, people say   teams, but what   team means. And I think it's the responsibility   shared, not diluted, that doesn't get to share. There is transparency,   there is   generosity, solidarity.   There is also what I said before, you know, like, say I'm saying sorry   or saying no or say I cannot do this. Team commitment, I think, is much more important and much more difficult to to achieve that just private manager decisions, you know, or or lead. So if we were able to magically   solve team dynamics   and make sure that people have this, sense of ownership of what they are doing because they participate in in in decision making. They feel sort of empowered within the team. I think you immediately get the best out of,   out of the team, really. Actually, in my world, we don't have project managers. We just have autonomous   independent teams that have some rotation in central roles,   quality and and other stuff. And we make sure that through that rotation,   the, everyone   that's factor goes up, of course, but also the, this feeling of of ownership. The in in engineering,   some people start with this obsession that technology   is and then in itself, you know, I I will go to this company or this project because because I like the technology, And that is fine. That's I think that's the first level of maturity that you can achieve when you go you know, you've got the degree or you have your first work, technology,   technology, technology. Then you find that perhaps technology is just   a means to the project. And then it's about the project, you know, and some people will switch to a different company or different organization because it's the project that is exciting. And the technology is just not so important. But eventually, I think some people   get to the 3rd level of maturity. This is my personal view of all this. Sorry. Which is, but whom I'm interacting with, you know, what is the team? What's the people I'm I'm, I'm having to negotiate over every day? Who are my peers? Who are the stakeholders?  

My customer,   my my friends or my teammates.   And then the pro is secondary, and definitely   technology   is   not so much important.   So   when you get people at the top   of this 3 tier system that I just described, you probably have the, the best brand management that you can have. That's very you know, it's it's super tough. You know, a lot of people just will just remain, where technology resides, and that's it.   Typically, also, you get people just obsessed with tools then, you know, and then you get project, which is much better. But still, you know, it's not the best   scenario you want you you can get. I think it's about,   team. So, yeah, it's my my my particular vision on this. And when we develop Tiger, we make sure that above all, it's about interactions,  

[00:40:10] Unknown:

and and, you know, people and teams. And continuing on that, what have you found to be some of the most common points of friction  

[00:40:18] Unknown:

in the life cycle of getting a project delivered? In general, well well, I think some of them we already touched upon, but I would say let me see. 1st, knowing what to do and who is involved or needed,   I think that's, that's a major problem.   It's super too old to say, right? Everyone is like nodding like, yeah.   Well, Tiger can help you by using custom fields. I can provide, you know, a nice template to feeling.   So, you know, exactly,   all this stuff. Also,   for multiple assignments,   but I think, most importantly, multiple   role estimation. So, you know, every role in a project   is, entitled,   if defined so, to participate in the estimation, in the definition and estimation of a of a user story or task. I think this is very cool. That's 1,   point of friction. A second 1   is that a product management workflow,   I think suffers greatly when there is either an explicit   or implicit split in the team, like creative   versus technical. You know, many tools actually just go for the tech people. Many well, the majority tools just go for the tech guys. And Tiger tries to solve this potential split   by welcoming everyone. So Tiger is not just the tool for the super techie. It's the tool for the whole team. And I think that really helps. Everyone on board, you know. Let me let me see.  

Another point of friction. Well, people not admitting,   they are overreaching.   This is very problematic   because it's not something people say,   but will manage is very powerful. So I don't know. Do you are you familiar with the,   with Princess Bride book or movie? Yes. Yeah. So you probably have heard about the Iokine.   Yes. Poison.   So Tiger Burrows the concept of Iokine, this deadly poison, you know.   I mean, it's it's a film from the 1980   4, I think. So spoilers are okay   today. But the idea is this fictional poison that is deadly if you if you take any dose at any time.   But you can get immune to the to the poison if you take small doses over time over a long period of time. And, you know, there's there's a moment in in the in the film where that is the solution to the conflict, you know. Now Tiger does use IOKIN   explicitly says, is this IOKIN for you now? Is this user story? Is this task IO kind for you?  

And if you say so,   I it's it's it's not asking you that in this way. I'm just betraying like that. You actually have just an an icon there with a with a   bottle of poison.   You say that, it immediately turns your avatar like greenish, like you're you're ill. And it's a funny way to tell everyone that for that task in particular, you're you're overreaching.   You might be overstretched.   You might suffer. And, and those iokine doses add up. So if you're going through a sprint and you see the statistics and you see 6 iocaine doses, perhaps you should go down. You know, say, okay. It's too too many doses. The great thing about this   small dose application   is that over time,   if you have been taking small doses in, you know, database and you're a front end guy,   if for some reason you have to take a big dose of that poison, which is database,   you will survive.  

Tricks that Tiger will use to prevent those points of friction taking place. That's that's that's an nice 1. Another point of friction, definition of ready and definition of done. Tiger offers some help there, but not a lot. I have to admit. 1 that has, we come across a lot, multi project commitment.   Just terrible. We see that all the time. People committing, individually committing to 1 project,   x number of whatever hours or, you know, effort or capacity. And then and then the next project and the next project, and they they just they don't remember exactly how,   but they ended up committing twice their, you know, weekly available time. So   we need to make sure that these project management platforms do alert you when you are committing too much,   overall. That is really a major point of friction because   not that way for other people. They are split over, you know, many projects.  

So   you have to be very careful with that. And finally, since we are an agile platform,   I think a point of friction is, well, agile anti patterns. Anti patterns are all over the place. You know, it all starts clean and simple. And at some point, people start wanting   the twist. You know, some twist within the agile frame,   agile framework framework to mimic   their reality   or their past habits.   You know, I call these, toxic twists. Those are hard to prevent. Tiger tries to fight hard against this toxic twist. You know, we we try to prevent them as much as we can, but it actually goes beyond the tool's responsibility. You know? Although it's true that by saying no to some features that we have been requested,   we at least don't reinforce   or accelerate those toxic twists. They might still occur,  

[00:45:26] Unknown:

but they will appear much later. So, yeah, those those are some examples of, common, you know, points of friction with, within product management. Yeah. It's pretty remarkable how many different ways any given project can be derailed, either at the individual or at the team level. But I particularly like what you were calling out with the I o k and also with   the notification   of the sort of overinvolvement   in multiple projects as ways to incorporate design as a subtle indicator to give some better context about each individual's   commitments   and capacity within a given sprint or within a given project so that other people within the team are able to gain that understanding without having to,   sort of consciously make an effort to go out of their way and ask about somebody's level of comfort or capacity  

[00:46:16] Unknown:

as far as what they're able to get done? Actually, that's where we took the name from, Taiga. So perhaps not everyone knows what taiga means. Taiga is this huge, massive boreal forests,   northern hemisphere.   They are beautiful, you know, beautiful. It's a it's a beautiful biome. And they're beautiful from the outside. You know, at a distance, you see them, it's like, oh, this is so   pretty beautiful. This is amazing. This is   pure nature. But you go into the taiga   unprepared,   and you die. And you suffer and you fail because it's deadly. And that was a nice metaphor for projects, you know. So from at a distance, from a distance, the project looks great, you know. Hey, new project. This is amazing. Wow. I'm so excited. Well, if you go unprepared,   you are gonna die. I mean, perhaps the metaphor is a bit too drastic here, but   you are going to suffer greatly. And so we decided 1 1 of the reasons to, name our platform   Tiger was to give you back that in that, joy in,   in going into the tiger or in in in in going to the project. So it's like, enjoy your project, you know, finally or again, or please, I want to enjoy my project. I want to enjoy the tiger. So tiger for us is a metaphor for projects with his,   from distance   and from within because because  

[00:47:32] Unknown:

all these friction points and everything. Yeah. That's definitely an excellent metaphor, and I I like the multilevel  

[00:47:39] Unknown:

symbolism that you're capturing within that naming. It's also green, which is great because it's Python.  

[00:47:45] Unknown:

And so as far as your overall experience   of building and running the Taiga project and the team and community, I'm wondering what you have found to be the most challenging or difficult aspects along the way, and what you have found   personally to be valuable  

[00:48:03] Unknown:

or unexpected lessons that you've learned on the journey. Well, I can tell you it was it wasn't growth. Growth hasn't been   a challenge for us. We were featured just randomly on Hacker News day 1. It was just a link, and, we got thousands of users right there, 24 hours. So we and we still have hundreds of new registered users every day. So our challenge has been really bandwidth. We wanted to remain independent and develop the product that we wanted, and it continues to be the case. And we wanted to be also   have a a sustainable business model. So want to be,   you know, have some revenue   and use that revenue   to further   invest   reinvest into the into the company. And so, you know, have paid work. So but you I mean, at any scale, you are going to have bandwidth problems. But, we have so much potential and you have to focus. We could do lots of stuff. You know, we have big plans, really. And we we have made some mistakes along the way because   we had limited bandwidth   and we have wasted some of that bandwidth. How? Well, I'll give you an example. We developed from scratch,   TigerTribe, or might know might not know about TigerTribe.  

It's a fully functional   gig economy   platform so that people can publish gigs, you know, piece of work and people can bid. You can only up bid because we didn't want this downward   spiral of prices. You can only up bid. And we thought, okay, so we have Tiger and then we have this gig economy. I it was this was 3 years ago. So this idea of gig economy was still, not that prevalent, I think. But anyway, we developed a massive platform to be connected with Tyga using Tyga's API, of course, so that you could use Tyga. And for any user story that you were unable to, you know, commit or whatever, you basically outsource that to Tyga Tribe. And then Tyga Tribe would just publish it, feature it, people will just apply, bid, a bid. You, you would say,   this I like this guy. I like this, whatever, and settle, you know, some contract and this and then join the Tiger Project and and do that work. That took us a lot of effort and energy,   and we didn't have the power or the or the sales bandwidth to, publicize that. So definitely bandwidth. And that that is a is a is a very good example because it's big and it has a name, but there's some other stuff that is not that big, not that important, and also was a waste of resources.  

Also, Tiger   does feature a SaaS service   service as a service model. You know, tiger. Io. You can go there. You can download the source code, deploy Tyga locally, but you can also just pay for the service online. It's it's a SaaS. And, also some challenges   has, has been,   arriving to a a correct, you know, right pricing model. What is the correct and fair pricing model? And and we're still working on what is the correct and and fair pricing model every time. We think like, is this fair? Is this not as fair as we should? So   so, yeah, it hasn't been   technology,   and it hasn't been,   community involvement. It hasn't been, a lack of features or a lack of feature request.  

It has been just that this is, a big potentially a big platform,   and you have to you cannot,   make mistakes in terms of allocation, you know, capacity allocation. And we have made some mistakes because the pump was limited. If we had 1, 000, 000 as other companies,   we might be able to waste some of that. Although I I feel dirty, you're saying that. Why waste 1, 000, 000? Just put them to good use. But, we have this, sustainable model. I think we're proud of it, but it has its limitations.  

[00:51:40] Unknown:

And 1 of the things that I do like about   the Taiga platform and the hosted offering   is what you're saying about the availability for some projects to be public or certain issues to be public so that other people can,   become involved.   And so 1 of the things that we didn't touch on yet is the idea of onboarding into a project which is exacerbated when you have new people coming project   and   for   a   the project and for a given task. And so I'm wondering   what features Taiga has to help with that and some of the ways that teams and project managers   can facilitate   an easier onboarding experience to either new team members or, people who are coming in for 1 off contributions.  



[00:52:27] Unknown:

Yeah. Well, and and TIGA in particular does allow for, public projects.   And,   and all private management platforms   are just all in for   private price. They don't they don't even consider that some projects should be public, perhaps because they don't have this open   source mind, and they think, well, people will just want to have these their projects private. So Tiger does allow for you to make those projects public as much as you want. You can make just some parts public. You can, limit the interactions or   the permissions that this anonymous user can do, you know, with that public those public assets that you're make you're making available. And whenever you make your product public, you know, you are not going to be charged. If you just you just do public projects, that is free.  

Unlimited. You know? Unlimited public projects.   And so you have this discovery,   section where you can just browse and and and look for projects that are looking for people. And, and then, you know, you can see, okay. Oh, this project is looking for people. I'm going to just go around and see what they're doing,   what what the teams look like, you know,   user stories that are open, tickets, whatever. So it's very nice. Tega just allowed for that. And we came from the community, and we we want to make sure that Tega helps the community. Now in general terms, I have my own opinion around how a good onboarding process should work for any project, not just Tiger hosted or Tiger. And I think well, there are many things you can do, but I think there are 3 big wins. In particular, software development. You know? So for development. 1, I think development   environment   should be super easy to set up locally. You know, the development environment is super easy. You you need to be able to just locally deploy that   and start, you know, doing stuff. An onboarding process should include the, you know, know how decisions   are made. You know, People should know how decisions are made and how to be part of them, if you can. And if you don't, if you cannot, you have to know that too. And, and also, you know, finally, to know where is my   to do stuff. You know? How is my work going to to be tested or validated? You have this. You have this development environment locally. The decision making process is clear, and you know what you can do, what you're expected to do, and how it's going to be approved, then that's great. That is a great onboarding process. Apart from that, you know, people should feel they belong to the project. We're not just coding machines. You know, we're people. So, so, yeah, the concept of team onboarding,  

[00:54:54] Unknown:

I think is key too. And given the fact that Taiga is flexible and has all these capabilities   for integration and extension   for working with other tools and platforms. I'm wondering what have been some of the most interesting or unexpected or innovative ways that you've seen it used.  

[00:55:11] Unknown:

I mean, since Tyga is non tech friendly,   there are   many unexpected examples.   But I like when people integrate Tyga into, you know, amazing platform   ecosystems. We see that a lot. I like, for instance, Fedora. I'm sure you're familiar with Fedora. People that are not familiar with Fedora is the community driven distribution, Linux distribution by Red Hat or supported by Red Hat. So they are defining a a whole new life cycle management process where Tiger is   or will be central   to that. And there's there's many, many different tools you can see from their, memo. Also,   I I mentioned this earlier.  

I mean, we were amazed   with this this email from this guy, Alex,   that had developed   a   completely,   you know,   fully functional app   just because the API documentation was working, was good, was up to date. So   from scratch, you know, without telling anyone, that was that was unexpected, I can tell you.   So, also, yeah, I think the love from the community   resulting in all those,   language translations,   that is great. We have fight to live support thanks to that or because of that. But I think perhaps the most truly unexpected ones or the most innovative are the ones we don't know about. We sometimes get a glimpse   of super big tiger deployments   in super big organization. I'm not going to name any, you know, any, but they're super big, well known. And sometimes we know they are doing something massive because we get support tickets   that were meant to be addressed to their local administrator. And it's like, oh, wow. You know? I shouldn't be reading this. Well, I should be reading this. It's it's, you know, it's addressed to me. And we immediately say, I don't think we could help. This is unsupported.  

Tyga on premise thing. Sorry. You know, just contact your local administrator. And then you see many different users and use cases for Talia. So many of them are either different fields that are not super development, like journalism   or lawyers or event   management or through the API,   crazy massive integrations with big ecosystems in very big organizations. So yeah. And when is Taiga the wrong choice for a given project or team? Well, if agile is really not your thing, then Taiga is not for you. I mean, you could still use the, ticketing system. You have that module,   very powerful ticketing system. But if you're really agile, it's not your thing, probably you're not going to get much,   you know, out of Tiger. This is going to sound naive, but when you don't trust your team, Tiger doesn't make a difference between   roles in the sense of visibility   or power. I mean, there's permission based role. We have that, and you can enforce that different people will be able to do different stuff. But in general, people can do stuff and then say sorry. So if you if you are the type of person that you   you think your team should be monitored, you don't trust them, they're great people but shouldn't be trusted with the key decisions or decisions   in general.  

You're going to feel Tiger is not on your side. Also, when Tiger is the wrong choice, when when you expect the tool to solve   your internal dynamics, that is the tool that's going to fix my problem,   my my internal dysfunctionality,   or when you need, above all, metrics, lots of metrics and and reporting. If you lean towards any of these use cases, you will feel disappointed with Tiger because it's it's not what we why we build Tiger, you know, to, be the replacement   for conversations   or to be able to use it for waterfall methodology   or to to, you know, percent also reporting and metrics. So, yeah, when when that is your focus, then is Tiger's clearly the wrong choice. And looking forward, what do you have planned for the future of Tiger in terms of  

[00:59:09] Unknown:

the future road map itself   or in terms of the overall capacity for community involvement   or business direction?  

[00:59:18] Unknown:

Yeah. So, we try to make every year, like, the there there's a theme. And, you know, some years' theme have been stability or performance, and years have been features. At the moment, our road map is about   business wise, we just launched,   a couple of months ago, the supported on premise Tiger instance.   Because   2018,   believe it or not,   we weren't we weren't prepared for this, but we got lots of requests for supported Tiger   instances,   tiger on premise. There was a backslash. I think a lot of people that were about to go to cloud,   you know, big organizations   just saw this camera channel and   data theft issues that even if they know they're not the, the reason for the attack,   they know they could be collateral damage. So they they fear that, and they said, okay. It's not the time to go to cloud. So we'll remain you know, we'll just run our own infrastructure, whether it's cloud or not. I mean, when I say cloud, I mean, when it's not your cloud. So we we were saying, no. We're just SaaS, but you can download Tiger. No. We are SaaS. You can download Tiger. Until we realized there was this huge potential   to support Tiger on premise because a lot of organizations say, if you do not give me support, I won't be able to deploy Tiger. It's just it doesn't work like this in in in my organization. So we were saying no until we we had to say, hey, look. We have to listen to these people. They love Tiger. They just cannot go to cloud. SaaS, let's give them Tiger on premise. So supported Tiger on premise.  

Clearly, it's it's part of the,   what, Tiger's future or Tiger's presence. Actually, Fedora is using Tiger supported on premise, by the way. Thank you. They are great great people. Tiger Seedtime. We have been developing   an estimation tool to make estimation process super fun and super efficient. And it's going to be great. It's going to be released, I think in July. And it's I think it's going to be loved, you know, by a lot of people. Like, oh, finally, you know, oh, this tedious process of estimation and, you know, team team coloration estimation,   this painful process. And I think we have come across the right process   with the right level of waste that will make it fun and productive.  

And you will get some quality or better than average quality   for your you know, against your typical average estimation process. So Tiger Sleep Time, wait for that. Also,   redesigned look and feel. I want to, you know, keep up to date within, with, more than UI standards   and best practices. We're going to,   develop a personal dashboard multiproject thing so you get a better idea of where you are at in terms of multiproject.   Also,   not just for yourself, but also be able to say, and Susan, you know, how's Susan across multiple projects and you know? So I think that's going to be great.   Also, more Kanban goodies. I think Kanban, we can we have a great Kanban module, but we can improve it, and we can make it better.  

And but most importantly, I think we want to reach out to more people, you know, as a community. And we want to continue to grow that community and perhaps,  

[01:02:18] Unknown:

hold our 1st, TigerCon very soon, I think. And are there any other aspects of the Taiga project itself or project management in general that we didn't discuss that you'd like to cover before we close out the show? I think we mentioned the fragmented nature of the market. And,  

[01:02:34] Unknown:

I think we are experiencing,   this,   how do you say, this,   aggregation   or this, yeah, of,   in just 1 company, which is Atlassian. Atlassian had Jiran, many other tools, and then acquired Trello. And so you have both ends of the spectrum. Right? You have Jira, which is overly complex, super workflow oriented for tech people platform. And now under the same company,   same umbrella, you have Trello, which is the simple,   workflow thing for everyone. And   there is there is no 1 that is challenging that. I mean, there are challenges. Tiger is 1 of them, but there's nothing   close to a a contender, really a contender. And I think 1 of the reasons   is that probate management platform itself, just the platform is not enough. And, we should be focusing   on integrating   1 or 2 more tools. Not just AI, any any platform out there, you know, that wants to lead the this challenge or this, you know, this fight against the behemoth, you know, because it's so big. I mean, I don't I don't do you remember   what was the   acquisition, but it was, like, $1, 000, 000, 000, something like that? Perhaps it was more than that.  

So,   the ecosystem,   the market is not just fragmented, but also   particularly, I think, problematic.   And so within   from Tiger's perspective, I think we should,   we should improve   Slack, Match and MOS, GitLab, GitHub, out of the box integration, and we should do something to counteract this this super big player that is, Atlassian. Because Tyga, as as well as other platforms,   belongs to this hypothetical   middle ground, and I think a roadmap should reflect that. So, so, yeah, that that is something very very, you know, related to our essence, our nature of a company, you know, our aim. So I just wanted to just   share that thought,  

[01:04:26] Unknown:

with you and and the audience. Yeah. Jira, in particular, has definitely been the main player in sort of the   canonical association   for project management platform and tooling.   And it's also the   exemplar of the tool that is   overly flexible to the point where,   you can customize it to do everything that you want, but then you have to dedicate somebody to be for that to be their entire job of just maintaining the installation. And so it's powerful and flexible, but it is also sort of all consuming and requires   a certain amount of investment and time and energy to make sure that it continues to be useful for the people using it. And so it's definitely great to have other options in the market that can be  

[01:05:11] Unknown:

more sort of purpose built and more well suited to certain scopes and scales of projects. Yeah. I think, to be honest, that all people will go for Jira because of Jira itself. But because the how integrated   Jira is with other tools that you know, for DevOps or for other stuff, for the whole life cycle management, for portfolio management. And it's like, okay. I'll I'll yeah. I know how to use Jira. You know? But, I don't think it is. I think,   it but it   is 1 way 1 way to win over the competition, to have the whole ecosystem, you know, and to you came from for this, and you have to accept all the rest or   most of the rest. But, yeah, that's the nature of of our market,   and our challenge. But as long as we remain independent and we have our agenda and we we we, you know, we stay focused   and and we we protect our values   and what we want to do, that will be okay. You know? We don't have to beat other companies or other platforms. Really, the world is huge, and there's a lot of people just that, you know, around the world that just need a nice tool for private   stuff.  

And so we see huge potential   just with,   newcomers.  

[01:06:24] Unknown:

Alright. For anybody who wants to follow along with the work that you're doing or get in touch, I'll have you add your preferred contact information to the show notes. And so with that, I'm going to move us into the picks. And this week, I'm going to choose a hydration pack that I picked up recently for taking on long bike rides and hikes with the family.   It was fairly inexpensive   and has a, I think, a 3 liter capacity, so plenty of water for a long trip, and it's got enough storage for snacks, etcetera. So, it was good price point, good feature set. So I'll add a link to that in the show notes. And so with that, I'll pass it to you, Pablo. Do you have any picks this week? Well, I have  

[01:07:00] Unknown:

just a general advice or a or a just,   1 thing I would like to share with people. Just, I think I mentioned that during my intro, And it's,   archery.   I really believe   archery, in particular, traditional archery. But archery is a perfect sport, really, for  

[01:07:19] Unknown:

all ages or, you know, conditions, physical conditions. It is it is,  

[01:07:22] Unknown:

amazing how,   you know, it's it's mentally challenging,   more than physically challenging,   but it's all about technique. And I would suggest that everyone that has, at some point,   dreamed about archery, the the this idea of, shooting, you know, bow and arrow,   check local archery clubs.   Or if they want to archery in the woods, there is this thing called archery in the woods called 3 d archery, which is also fun. And,   yeah, that is, you know, just piece of advice on physical activity that is fun with friends or alone or family   for everyone to enjoy. It is,   an underrated,  

[01:08:06] Unknown:

sport. Yeah. I'll second that. Archery is definitely always a good time. And so I want to thank you very much for taking the time today to   share your experience of building Taiga and   working with project management.   It's definitely something that we all work with in software, so it's good to have some perspective both in terms of the feature set of Taiga and also just project management in general. So I appreciate your time and effort on that front, and I hope you enjoy the rest of your day. Thank you very much. It's it's been a real pleasure,  

[01:08:36] Unknown:

talking   to you.