Jan Ainali – FOSS behind the scenes - the center stage is not enough #FOSSBack

This talk discusses the challenges of using proprietary tools in the realm of open-source development. The speaker shares their background as a consultant focused on promoting open knowledge and their experiences within the Wikipedia community, noting the extensive use of open-source software in their workflows. They highlight the contradictions that arise when organizations advocate for open-source solutions yet utilize proprietary tools, which can lead to cognitive dissonance and fragmentation within communities. The speaker emphasizes the importance of fostering an open-source ecosystem while maintaining flexibility in tool choices and urges attendees to strive for gradual shifts towards more open practices, thereby enhancing inclusivity and sustainability in projects. They also touch on the implications of geopolitics and data privacy in tool selection, reinforcing the call to prioritize open-source alternatives for long-term project viability.

Oh, thanks. So, this little bit of cryptic title, uh, I'm going to explain it in the media in the beginning, so you don't need to wonder about it. I think most of us here, maybe all of us are sort of involved in some sort of open-source project that we're building. That's the center stage, and that's what we usually are talking about. Now I'm going to talk about

the tooling that we use when we're doing that sort of the behind the scenes. And I thought that was fitting because this is backstage fast. So it's uh could be worth talking about. The slides are available atina.backstage 2026. There's some links to sources and further reading. I'm going to show this in the end on the very last slide. We are going to have it up for a

long time during the Q&A so you'll have the chance to to look it through. So a little bit about me but not about me but rather how did I arrive to this? So while today I'm running a consultancy called open by default where I help organizations become more open with open knowledge open source open license and source but I came in to the open movement through Wikipedia

as a regular Wikipedia editor. And Wikipedia of course is under a free and open license. But you might not know that also the software it runs on Media Wiki is under a free and open source license. And not only that, the entire tech stack that they're using in production is open source and they're hosting it all themselves. So there's a very strong ethos in the Wikipdia developer

community to only use open source software. But the further away you come even within such an organization from actual developing and running things, the more likely or the more risky it is that you will encounter other types of proprietary software. So for example, if you're want to take a look at the design files and templates that's in Figma. If you're joining the annual conference, well, they have

event free and open source at their event platform, but as a speaker, you join through zoom and it's pi through YouTube. So even in a in an organization like that and the further away you go into regular office things, I think they're uh all their internal meetings are on Zoom and the chat is on Slack. and I'm a maintainer of an open source uh project myself gov

directory I'm in the advisory committee for open refine which is an open source tool to clean messy data and I used to work for foundation for public code which is an organization helping public organization to collaborate when they develop open source software and in none of these three which also like is for open source we were using all the a open- source software there were always some

proprietary tools. So with this entire talk I want to put like in the beginning this is not a rant towards anyone using this. I'm not angry at any project for having some proprietary tools in their software chain or tooling chain. Rather feel this coming with empathy and understanding that it is not very easy sometimes and with a perhaps a hope for inter inspiration and motivation for you

to change and move strive towards more open because there is a contradiction in using proprietary tools when you build open-source software you Don't build it by chance. You don't choose to be open by accident. You probably have some very strong ideas about the value proposition that your software being open might actually be an alternative to some proprietary tools even if you're not at feature parity just because

you're open. there is a sort of like a cognitive dissonance arguing for use my tool because it's open and then you go use some other closed tools and not using the open alternatives. You're not listening to your own arguments because there are some restrictions coming along with any proprietary tool. That's sort of the business model. They're often also not by accident. It could be something that you

cannot export the data at all. Maybe not in the format. Maybe you don't are maybe you're not able to modify the working environments to fit exactly what you need. And this becomes a problem because you're sending a signal by using this. And you might send a signal by you're starting out with one tool. Maybe you have Figma as your design file tool. And then you will well

well the next thing in the tool chain we can use a proprietary tool for that as well because it's the same people and then you start add on more and more of this. So you're shaping the culture by starting out there and I don't think anyone ever had some sort of like mastermind planned. Oh no, now we're going to start use proprietary tools. Uh it's rather very

pragmatic. It's solving a problem in the moment. that there someone has a need that they right then cannot find an open- source tool that is solving. So they're grabbing for something that they do. It might be something as easy at oh there is an open source project doing exactly the same but I need to host it myself or I can just get it as a service from

this proprietary thing. But it starts this slippery slope into less and less open. And this is not a purity test about being so open. You can be for some people that is fun and that's all right. But my point here is that it's actually creating some exclusion. Some people cannot participate or some people feel that they cannot participate. It could be something as basic as technical access

to the tools. If you're choosing a proprietary tools that requires the user to run Mac OS, for example, that might be an option for many people to join. And here it might be sort of like, oh, it's fun to have Linux on my side computer as a fun thing. In some parts of the world, that's what people can afford. And I'm not saying that all tools are

available on open platforms, but if the tooling you're choosing are open source, at least there's a theoretical possibility for someone to port it to that platform that you're using. And we've heard too many times already at this conference about geopolitics in the world. How that has influenced many uh software developers and since this there have been many more but there was this I think there was maybe

exactly one year ago when organic maps got blocked because of one contributor being from Russia which are under sanctions. So GitHub had no choice. That wasn't them being evil or anything. They just got this from the authorities that they need to block. Organic maps. I think now have more mer moved on to maybe codeberg. Uh but I don't think that this is likely to become any less.

If you're looking at the news any day, it seems like it's really really big. And you also see it sort of on the flip side where you see regimes or administrations wanting to get to know who's who are developing these tools. And then if someone is in a jurisdiction where their administration is likely to ask the platform to give them the data, they might not feel like

they can afford to join for their own personal risk. And you might think, well, I'm just building this health app and uh we're tracking menstrual cycles or something. Surely that's not something someone would look at. But in some parts of the world, you might be on the radar for that. Or you might think, I'm just building something very technical. We're enabling end-to-end encryption in chat. And that

is also something that uh some people would wedge their way into. So you never know what kinds of things people will want to know about. And I'm starting with solutions already even though we're just in the beginning of the talk because some things here you can sort of like mitigate by self-hosting then you know at least what you're storing or if you been using open source services

you can also know what's what kind of data is in there what are the risks and you can also think about where these servers are being hosted. If you're using services else uh buying services or free services somewhere and you might think you pick a jurisdiction that is kind of friendly but it's also good to know that you might just be an election away that not being

so friendly anymore. And of course this is part of the business model is to build a platform dependency to become locked into their system. And it's so very easy to be drawn into this to fall for the free tier because you're an open source project. And if you're not able to take your the the what you're using this tool for and move somewhere else, it can become

a single point of fail failure. And I think we've seen that in this winter and fall. a couple of big services uh coming down and taking large large parts of the internet with it. And this is of course just part of this term that Cory Dotov made famous or maybe he even coined it and shitification. And I think it was an emergent phenomena at first. I am

a little bit afraid that it's actually starting to become a playbook instead now where you first want to get as many people into your uh ecosystem or in their platform as possible to get these networks effect so people feel that they cannot leave because all their friends are already there. And then when you're in that position, you can start extracting more value. Sometimes by making some of

the earlier features only available for paying customers and also by extracting more and more data uh and then also turning that for uh for the paying customers also making that more expensive. You might also be up to the whims of a service. We have seen a couple of very one-sided terms of services where they say we can terminate your contract or your service anytime. We don't even

need to give you a reason. So every day you wake up, you should should be happy that you're still get to use it. But we also see a lot of changing terms of services. Maybe you're picking a project that feel oh no this actually looks okay today or this looks like ethical. Then you get an email. we're changing our terms of service. You don't even see the

changes there. You have to click through and read legal lease. And perhaps now they're also saying we reserve the right to use all data you're putting into our system into training our AIS. Luckily, we have the open terms archive now who's keeping track on a lot of these uh big players and providing diffs and also make a lot of noise. So check them out. They're really good.

And of course I think we have seen a lot of popular Google tools for example being sunset uh way ahead and you have nothing you can do right now we have also have Windows 10 being sunset and I'm not saying that open-source tools are not being sunset that also happens but if you're in the community you can influence it maybe you can even pick up some work

and help doing something and if worst come to worse you at least have the theoretical possibility that you can take the code and keep maintaining your own version. Although as Mira said in the talk yesterday, you might also need some capability to do that. It's not just doing it. And perhaps a little bit more subtle is that it can create a power imbalance in your project because

especially if you're using tools that have some sort of paid tier where people with more money actually can get more from the tool. But there are also other things that they're more likely to get training in the tool. And this power imbalance, it's not that someone wants to do something bad, but it is emergent from that if there's a group of contributors to your project that is

more effective or efficient, they will land more code and it might slant the direction of the development in your project. So you're seeing what your road map is stating is sort of being overtaken by actual code being landed by the most efficient. And maybe that is good for your project. It's at least something to be aware of that it can happen. And all of this is a

lost opportunity. You're feeding big tech. Uh when you're doing this, you're feeding them with metrics, usage data, sometimes with actual data. Maybe you're paying for some services, but where you actually are giving them is cloud. If you're some kind of success in your open source project, they're very happy advertise that or talk about, hey, they are they are using our system. We really good and cool. So,

what can we do? Well, we can start building your own ecosystems. And if you're using open-source tools, you can help out by filing bug reports. If you have some technical capability, maybe you can submit patches and building features. What you really should be able to do is to improve the documentation because even future you coming next year and reading up on how how did I do this

with your this tool, if you improved that, you will be better off. But even more so, if this tool is an essential part of your workflow and everybody coming into your project also needs to read that part of the documentation, you're really helping them getting up to speed quickly if you help other projects with their documentation. And one of the big losses is that you might lose

idealists. These really good false contributors with uh a lot of ideal. They might not join at all. Or if they're joining, maybe they're not joining your community call that is using this platform that is harvesting video and voice to to save. Or maybe they're not joining this chat platform where you need to do an age verification sending their ID to a sketchy player across the sea. If

you're lucky, they're at least staying in it. But they are often very experienced and know about what the harms could be and they care very deeply at their freedom. So they might be voting with their feet or putting their foot down and not joining these things. and that that is a big loss for your community. What we have seen also sort of the flip side is that

they might be bringing their tools of choice because they have realized if I use open-source software as tools, I can go from any employer to the next and I'm not locked into only employers using this specific tool. And then if you're using it, you will uh benefit from that. But the proprietary tools, they are so much better. And in sometimes, yes, they are. But we're building us

into a SL convenience catch 22 I call it where the head start that they already have if we keep giving them the knowledge of how their tools can be improved just by using them. We cannot catch up with the free tools. And it might be very difficult to break free, but we we really got to try it and try to contribute to the open ecosystems and don't

settle for these quote unquote bad But everyone is already on the platform. And that is perhaps the hardest part of switching something because you're moving to somewhere no one will find you uh organically. But we've also seen in the past that networks effects are not bound to last forever. We've seen big platforms fall and sometimes being taken up by some other big platform. But I think here

is where we can do a change. And I heard at the Q&A at a talk yesterday, there was an open code forge saying we are already having good technical development in features, but we're lacking the network effects. So you can start by just joining there, set up a profile, see and maybe do something there. So you give a signal, talk about it that this is actually happening,

that these are uh platforms where there's uh life and experiment. Maybe you mirror a repository. Maybe when you need a new tool, try to intentionally choose an open tool. And when you're switching, migrating from one tool to another, do it with some grace periods. And if it doesn't really work in your community, try then to to step back. It's never too late. It's never early enough. You

should have done this yesterday. But if you happen to be paying for a subscription lasting another 6 months, well then you extract the value for from them and make a plan how to shift afterwards. And if there's one thing that I want you to take with you after this talk today, it is not all or nothing. It's not a purity test. This is for the sustainability of

your project. So start small, move forward, do something and use the digital comms. Use it with love and care. There's a lot of different tools and there's some tools that are sort of generic for any kind of project. I listed a few here where I think there are some really good and mature alternatives that you could use and there's a lot of lists of tools. There are

lists of European alternatives. There are list of how to do a switch there. Last link here is also a list of lists alo so so so uh open-source software being used in public administrations these kinds of cataloges so there's there's plenty to choose from and change is possible and talk to your community maybe you want to start with something that is sort of peripheral it won't have

a lot of impact if it if you struggle with the change. Maybe you want to start with something where well if something happens here we're really doomed. So maybe you need to start there. But talk with this with your community and make one change and evaluate how it's going and then you make another. And all during this, radiate the intent why you're making the change. Because if

your community knows why you're switching tooling and why that will benefit the community in the long run, that will help. And if the community can see that change will be possible. And when you succeed changing one tool, that is going to be contagious and people will want to do it more. And don't beat yourself up if you're not perfect or not succeeding. We're living in an imperfect

world. We're trying our best to do better. So in summary of this is I'm coming back to the beginning where I said it was not an accident that you cho chose to be open source. Maybe you even had long debates what kind of license you wanted to use for your project. if you wanted to have a copy left or a permissive But let these values that sort

of that is reflected through your choice in that be reflected in your choice of the tools that you do so that you get rid of this cognitive dissonance that you might not perhaps feel like a hypocrite in the argument when you should choose my project because I'm open but I can choose whatever I want because I think that even though free and open source software are defined

by various criteria and some institutions of licenses I think open source is more than those licenses it is a culture we all belong to different communities and I guess to together here we're sort of also a meta community of sorts and we have a freedom allowed to us by these licenses So when you go out there, don't try to build freedom upon a foundation that you don't

control. Try to be master of your own house. And I think with that we can have some questions. Uh from the bottom of my heart, thank you so much for talking about this. Uh I was the person who spoke up uh yesterday upstairs about software forges uh that need the network effects. Um so again, thank you very much. Uh network effects keep me up at night. And

uh I really just wanted to reiterate um for your audience that I love receiving patches from contributors. I love uh when people step up to maintain the code. But by far for me and for my peers at other platforms like Codeberg, the most important contribution you can make to an open tool or an open platform is your vote of confidence by putting your project there by depending

on these tools. It's by far the most important thing you can do to make open platforms possible. >> Thank you. Thank you. And I think that's also something that is also a very easy first step for all of us to do. Show that we have confidence in these tools. We have another question from the online people. Thanks a lot for the interesting take or talk. Uh from

an operational point of view, however, I claim that many developers in their professional or in their profession are restricted by their employers regarding tools or tooling meaning that closed source tools are usually the way to go. How would you trigger cultural change in the employer side? Oh, that's that is an excellent question because it depends on the organization and it usually becomes more difficult the larger the

organization is. If you're just a team of 10 employees, then you can have a conversation and people will understand why you would want to use uh a certain tool. But if you're in a a couple of thousand people or or something and your department is maybe a hundred people, it becomes much harder to do that shift to get to choose uh what tool you want to use.

And I think one of the ways is learn the tools so that at least you know how to use them because then you can also show what value they have. But in some places and I think especially if it's ingrained in the walls maybe the best way is to actually vote with your feet and move somewhere else where you can be happy with the tools you get

to use. >> So I think everybody is stunned and thanks for the talk.