Ivana Isadora makes FOSS and takes our Twitter mic from September 02 to 09. Thank you, Ivana Isadora!
Before I start, I’d like to thank you for letting me participate in this cool project!
My name is Ivana Isadora, and I’m a writer, translator, and FOSS advocate from Croatia. Technically, I don’t make FOSS - I write things that help others make use of FOSS. My contributions to FOSS projects and communities have primarily been focused on promotion, marketing and documentation activities; most notably in the KDE community where I worked on revitalizing the Promo team.
After studying English and Swedish in college, I married my love for technology with my writing skills into a career in technical writing, which is what I currently do for a living. In my free time, I’m usually reading or dabbling in photography, cartography, and amateur meteorology. I’m always looking to learn something new, so a while ago I started learning to code properly (instead of just copy-pasting things from StackOverflow). The last thing you should know about me is that I spend entirely too much time looking at memes online.
In my technical writing work, I’m currently involved in improving API design processes and documentation by writing API definitions. More specifically, I’m working with a number of tools to describe existing APIs using the OpenAPI specification.
In the KDE community, many exciting things are happening, and although I’m not directly contributing to all of them, I will still talk about them. :) First of all, the development of the Plasma 5.20 desktop environment is on fire 🔥🔥🔥, and our tireless contributor Nate Graham regularly reports on the juiciest features and bug fixes on his blog.
In KDE Promo, we’re planning a pilot project to build a worldwide network of local representatives to help promote the KDE community and software, and increase diversity in our contributor base. We’ve also started posting weekly tips and tricks about Plasma and KDE apps features, so make sure to follow the KDE community on social media. In the documentation department, a major effort to improve existing resources for developers and build a developer portal is currently underway.
Finally, the biggest, most important KDE community event is starting this week! Akademy 2020 will take place from September 4 to September 11 completely online, and completely free for everyone. You don’t have to be a KDE contributor to attend, so if you’d like to hear any of the amazing talks in this year’s schedule, there’s still time to register for the conference.
The most interesting thing about the OpenAPI specification is that it’s an open standard for describing RESTful APIs - the key part here being “open standard”. The decision-making and the development of the specification are transparent - you can go and read all of it on GitHub at any time! This is important because open standards prevent vendor lock-in, unfair competition, and other unsavory business practices while highlighting the advantages of FOSS. The more companies and communities embrace OpenAPI as the standard, the more opportunities for collaboration, integration, and research there are.
As for the KDE community activities, the promotion-related ones are obviously the most interesting to me (which does not mean the rest are boring!). Promotion-related activities used to be perceived quite negatively in the FOSS world, and were often dismissed as “that marketing crap”. In KDE Promo, we’re continually investing in efforts to change that perception, and we try to build meaningful relationships with developer teams, because without their work there’d be nothing to promote. We highlight the benefits of talking about the FOSS they make, and discuss challenges in the promotion process so that we can tackle them more efficiently. Sidenote: one of my favorite conference talks ever is “Do Good Things and Talk About It” by Markus Feilner, which explains perfectly why promoting a FOSS project is critical to its success. On a day-to-day basis, the most interesting thing is how all sorts of creative (and sometimes crazy) ideas for promoting KDE come to life in our brainstorming sessions. It all happens organically, by playing off of each other’s experience and inspiration, and the “eureka!” moments it produces are priceless to me.
As a kid, I was fascinated by computers and begged my parents to get one. Before they actually did, I bought IT books and computer magazines with my pocket money, and tried to learn as much as I could from them. Looking back, it’s really fitting that my first contact with technology happened through other people’s writing.
The first computer in our household came with Windows ME preinstalled…yeah, don’t ask. I quickly became unhappy with how restrictive (and expensive) a lot of proprietary software was, and I figured there had to be something better. And there was. I first heard about “Linux” as an “alternative to Windows”, and then started exploring more about the concept of Free and Open Source Software.
What appealed to me the most were the four essential software freedoms; particularly the one to “study how the program works, and change it to make it do what you wish”. Although I’m not a developer, I’ve always enjoyed tinkering with all kinds of settings, and understanding how software works has always been important to me. The fact that FOSS not only enables this, but actively encourages it, made me start participating in communities where people shared the same interest.
The desire to “pay it forward”. I wanted to try being useful to people who helped me while I was still a beginner and didn’t really know much. While I couldn’t help by contributing code, I could assist other beginners with troubleshooting and setting up their systems. This all happened online, on forums and in IRC channels, although our little Croatian FOSS community did have in-person meetups a couple of times every year.
Later, I gathered up the courage to lead promo activities, publish tutorials and app reviews, translate news articles, create social media materials, develop content strategies and even take part in conference organization. It’s all about finding a gap and offering to bridge it with what you do best.
Contributing to FOSS projects can be a highly rewarding experience and open up many opportunities. Just knowing that the code you wrote, the interface you designed, the user guide that you wrote or translated, or the promo video you recorded is going to reach dozens of people around the world… that’s a fantastic feeling in itself. It gets even better when you hear the praise from those who use the FOSS you make. On top of that, you get to meet people with similar interests and build relationships that go deeper than comments on a pull request. You gain valuable experience working in distributed teams, overcoming all kinds of communication challenges, and learning about different cultures and approaches to solving various problems. If you can pick up a skill or two along the way and convert all that into a job opportunity, you’re golden.
However, it’s not gold and glitter all the time. For every person who likes the FOSS you make, there’s going to be at least one who hates it. As with most other things in life, I believe it’s important to be realistic and not expect too much. If you’re planing to do it purely for personal gain, you’re probably going to end up disappointed. It’s about building things together, as part of a community, not about drive-by typo fixes just to get a T-shirt and never return again. Also, it’s entirely possible to regularly contribute to a FOSS project for many years, and still never get any “fame”, fortune, or professional success out of it.
Still, if you believe in an idea, if there’s a project you want to support, or if you just want to show gratitude to people who make your favorite FOSS… by all means, start contributing. In most cases, the good will outweigh the bad, and you will not regret it in the end. :)
That depends on the time and effort a person is willing and able to invest in a FOSS project. If they’re new to FOSS or not very tech-savvy, or if they don’t have a lot of time to spare, donating to a project is probably the easiest way to contribute. The donation doesn’t have to be huge, and it’s a nice way to support a project, as it helps cover various maintenance costs that add up behind the scenes. A step further would be to organize a funding campaign at one’s school or workplace, especially if the FOSS project they’re looking to support is already widely used there.
Beyond that, it’s good to have an idea of how you want to contribute. What types of tasks do you want to do — and why? What are you good at, and what do you think you’ll enjoy doing for a while without it becoming tedious? When you have a plan, you can start reaching out to projects and asking them to point you to some “good first issues” and “junior jobs” (here’s a little secret: you can also look up issues with those labels in project repositories ;)). Generally, the majority of FOSS projects and communities will not expect you to do everything on your own, and you should not feel ashamed to ask for guidance at any point.
Keeping projecs and communities alive and thriving. Having long-term plans for what happens if the maintainers get “hit by a bus”. Making sure everyone’s opinions are heard and valued, without elitism and exclusion derived from discrimination. Resolving conflict without jeopardizing the future and/or integrity of the project. Resisting trendy intrusions from the proprietary software world and “solutions” that promise convenience in exchange for privacy. From my perspective, the biggest challenges are often with the “people” side, not the “code” side of FOSS, although there are exceptions.
How can those be resolved? I don’t think there’s a one-size-fits-all solution. It’s more about finding and maintaining a delicate balance that works for each particular FOSS project. It’s hard but not impossible, as long as you keep the project’s best interests at heart, and if you’re at peace with the fact that you cannot please absolutely everyone.
Onboarding can sometimes be difficult for both sides - the new contributor and the FOSS project they’re trying to join. The project might not have enough resources to invest in a proper onboarding process, and the new contributor might be confused by the information they’re getting, or unable to find the information altogether.
What can help is a bit of empathy; again, on both sides. New contributors should understand that the project is (largely) maintained by volunteers who might not be available 24/7, and that doing independent research goes a long way in showing how serious someone is about contributing. Existing contributors should understand that new contributors might not know the language or tech jargon very well, and should not dismiss their questions with rude “RTFM” remarks.
More technical solutions involve improving the onboarding process, and by extension, the project documentation. Large FOSS projects can establish a mentorship program, while smaller ones can dedicate one or two people as Onboarding Officers. Centralizing the onboarding resources can also help. Instead of linking to five different “Getting Started” pages on five separate subdomains, have it all on one cleanly designed page, with sensible navigation, functioning search, and content adapted to different skillsets and experience levels. Last but not least - collect feedback from new contributors, listen to their pain points, and use that information to make it easier for the next person who wants to join your project.
If you’re someone who makes FOSS and you don’t know what to do with the documentation, or if you’re not sure how to promote your project, feel free to contact me. I would love to help if I can! You can find me on Twitter as @ivana_isadora.