Mustapha Rufai – Docs, Demos, and Mentors: Growing Open Source #FOSSBack

This talk presents Mustafa Rafi's insights on building and maintaining open-source tools, particularly focused on addressing the challenges faced in unstable environments. He discusses the importance of effective documentation, practical demos, and mentorship in fostering user engagement and community growth. Rafi highlights the need to create a system that accommodates both consumers and contributors, emphasizing that understanding user dynamics is crucial for successful tool adoption. He introduces the concept of protocol engineering, which includes developing fault-tolerant systems and establishing an environment that encourages continuous improvement and learning among users. The session also shares strategies to create a mentoring framework that cultivates a supportive community around open-source projects, ensuring sustainability and growth.

Nice to be here today. Um my name is Mustafa Rafi. Um I am speaking and sharing my story um around documents, demos and mentors around opensource tools and how it works generally from my own experience waiting for um fintex and products um from Africa. So today we are going to look at a couple of interesting concepts that allows us to learn about um how to build opensource

tools environment where things are not necessarily stable. So I am going to describe to you um an a that I call um from the modoto engineering. Welcome everyone to this session in 20 2025 um with the global open source and we have so many metrics in which we use to define this kind of story. The ITU from United Nations body um they released a report last year

called age gap and in this gap um they talked about people who use the internet and the kind of cost and um infrastructure that they have access to. And then we now look at the two different kind of dynamics the consumers and the contributors. We that there are people who create open source tools. There are people who design that document and then people who consume these tools

too. So our goal now when we want to look at these tools and how it is being created and how it is being cons, we want to consider how humans in different regions of the world are able to create an environment where irrespective of the stances of that tool they are still able to use that tool. So I started my career in Lagos and um I saw

a very interesting um gap. If you use an open source tool generally anywhere there is an expectation that the tool um is unmetered as high-end um hardware if you are using um Ubuntu any of those tools right you are expected that the tool and when you use them are your users they have high-end devices and you are building that is the kind of persona that you have

in your mind when you are building for them But the idea is that there are some set of indiv um I end networks to be able to consume those open source tools. So today we want to look at how we can bridge this gap between the framework that I have built um and it is battle tested in the most demanding environment which is all right so we

may be familiar with the idea called the grow delux um infrastructure there's an interesting story about a young girl who eating and testing different meals and in these different meals. Um she came to the conclusion that one is too hot, one is too cold and the one in the middle is pretty much um not too hot, not too so ideal state that we all to get. Everything

that we are building, we are have this ideal state in our system. If you are building um if you're building um the airport industry, for the aeronautics industry, if you are building um open-source systems, if you are building operating systems, you are expected to have this um Goldilocks state where things are just normal. But then what happens when you cannot estimate the changesment in which things occur.

That is what we refer to as this protocol engineering. And what it brings together is this. We are going to look at the docks, the tools and the individuals, the mentors that allow us to be able to build tools in an environment that is not stable. So that is what we are going to describe. Um just before I go on myself, my name is Rafi Mustafa. I

am a software engineer and technical instructor. I am based in Los N and I help products and people build tools and help them to maintain that stable relation between um chaos and conformity users would love and users would love to use at all times. So let's get right into it. In the real world experience, what I am advocating for is Building a tool and engineering tool is

select that there are things that would fail. There are expectations that will fail. For example, if you look at this image, there are some expectations for you being you know that if the person in front of you moves, you yourself you need to move. If you don't move, you are going to cause chaos because gridlock between you and those people at the back of you. So this

is just about this is not just about acting around. Um it is a practical implementation that we see in the 2020 205010 um international standard for software engineering where we are specifically looking at fault tolerance and the ability for us to be able to recover. Now I work in real life um at several fintech where we engineer something called partial success. The scenario um for a fintech

will be that um you have a ledger that you want to update butions are failing. Now in open source when you have your documentation and you want your documentation to be accessible to people but when somebody comes to that documentation in the first five prints they are confused they are not able to use your API they are not able to understand um the demos they are not

able to understand the endpoints that you have you have your readme right and your readme um implies that it is supposed to be a happy part, a normal part, right? But the reality says that people when exposed to that readme, they are not able to use it. It is confusing them, causing a barrier, a block on their part to using your product. allow people or we are

expecting that people have a direct way in which to use our product but the reality says otherwise in that these app necessarily always work right it fails in the ILE E 1028 standard for technical reviews so the goal and the idea is that we want to move away from these antifragile documents documentation that doesn't necessarily describe but anticipate and mitigate the environmental failures that we are seeing.

So what um real life experiences do I have that I can share with you? For example, a few years I have been involved in typical mentoring and creating documentation um for individuals. Um in my work with rise west uh with car constraints called this um generally there's an alliance for affordable internet report that is in emerging um emerging markets um that you can download online. Now what

this report says is that a research area pioneered by the Inc. right? Um allows us to be able to see that people are struggling to be able to use documentation that the community don't necessarily um conform to. Such that if you have support and people are complaining raising issues but that dichotomy between the issues being raised and the documentation being written then there is that difference and

that this is new barrier for entrance for people who want to use that product at any point in time. So for example um if you are building demos that run offline via um docker um or you are mocking it on your local server now we aren't just helping individuals in that sense people you are using that documentation and people are able to understand what you are building

but at the end of the day there is a barrier and that barrier want to breach. So when we try to remove and breach um where when we try to remove this barrier what now happens is that they you can see um a people that are going to be coming into that product and using it. So the next part of this um is how do we scale

the idea of um building this barrier and allowing people to continuously use your product your open source product. So growth in open source product isn't just about the code that you are writing. It is also about the community spec particularly and how the dynamics of that social interaction and the people that you have. So to scale our program for example at um school um in Berlin there

is something I refer to as cognitive apprenticeship. Um so this is not just around um the typical volunteering that we are familiar with. um what we call it or what I call it is knowledge that we can share in the immediate moment with and it is not just about sharing it with you with individuals in your own community but making sure that it is evergreen for other

people in the community to be able to use. So what this does is that if there is a pattern or a mentorship program that brings new entrance for people to learn the product um and then as they gradually become good at that product then they can turn from just learning the product to being the mentors in that product. So there are several ways of this. For example,

um recently Claude, it is not a open source product, but you will notice that they released a academy similar similar to um many other open source tools. Now the goal of this academy is that they can bring in new entrance. They can standardize the knowledge that people have and then they can release that. they can create um around it which means that people can they say I

am familiar with this product there's a standard documentation around this product and people are learning yes this product constantly from us same thing um the Linux foundation does um if you remember there is a diversity report that they released and what this what this does is that they were able to tell us that there's a contribution gap between um those who are using the product and those

who are actively developing the product. So what we want to do to scale product that you have is you want to in a standard way for people you can call them student of that product. What what that would do is that when they are student they learn that product that focus is on learning that product and then if it is in a standard if you have a

standard separate academy for it what that will mean is that they would learn the product and as they progress in that they learning part they now become mentors to those who are coming behind them. So their diversity would now increase. Some go into documentation, some go into active development, some will go into community management. And in all these parts they are not just themselves being users of

the product, they are also back to that product such that it now becomes a cyclic cycle of those being introduced to the product and getting them to become expert in that product and them being mentors. back to that product. So this here is what I refer to as our approach to being to being able to understand the idea of opensource tools and how we can use mentorship

and docs and documentation with me um demos to constantly grow your opensource product. So you will see this in real life in many different places. For example, um if you look at similar products um for example there is um Linux and you look at the um the entire system of Linux opensource um Linux foundation itself there are free tools actively being given to people students um users

of the product that allow them to come into that system allow them to without pressure learn that product carefully and as they're learning the There are other mentors that are and or that are available to throw them into the uh deep end of the sea to throw them into uh making it uh making it easy for them to enter into that ecosystem. Another part that we need

to consider very important is making individuals being comfortable as they use your This here is when we refer to the community. Um so a very important role here as you as you are allowing people into the system is to have a rule based approach such that any person coming into the system understand the code of conduct for that community. So it is such that it is easier

and comfortable for anybody coming into that system to be able to operate. In this case, if there are outliers in that system who don't conform or don't want to abide by that rule or the code of conduct that we have in that it is best in that moment to remove them from the community. That way you can foster you can foster the growth and the product that

happens in that system. Right? All right. So at the end of the day um the goal of this presentation is to explain to us why the opensource product that you are building are not growing and what I have described to you are three system ways in which you can use um something called the protoc engineering system to grow your open source tools. How can you do this?

The first way is to ensure that you have the documentation, have the docs, you have the community and building this you build a system of cyclic mentoring um and cyclic student mentors approach that allows everybody to be able to use the system to grow their community. What this will do is that it creates an everlasting strategy for you as the open source owner, as the open source

maintainer to constantly have users of your product. Not just users, to also constantly have people who would improve your product for you, people who care about your product and how this product is going to um impact the community you want to use. So as you create more product and you want it to be much more robust, you should as you think about this happy part, this ideal

part, this goldilocks part, do all not too cold, you also want to consider the part that is expected, the reality part where there is um chaos in the industry, where there is chaos in real life and you want to ensure that you are standing somewhere in the middle that irrespective of what happens on the extreme ends of these cases, your product, your open source tool continuously grows.

In the next year, in the next two years, in the next 3 years, your opensource product will still be alive, will still be growing because you are constantly injecting new people into the system. And these new people are constantly being mentored, being guided by those who are coming, who are already in the system, who are already conversant with the system. And how do you maintain this echimony?

You maintain it by by having a code of conduct, a guide for your community that you constantly check and you constantly review against those in your community. And anytime there is any system that breaks your code of conduct, you try to manage and make it come back into that system. It is not a perfect um it is not always going to be perfect but what it ensures

is that there is no longevity there is growth and there is um harmony for anybody that constantly wants to be in your system. So the next time you're trying to build an open source tool or the next time or if you're currently building an open source tool, try to consider this. Try to have that system that allows you to be able to constantly manage those who are

coming into the system and those who are going out of the system. Thank you very much for joining this session. Um once again my name is Rafael Mustafa. Um I have just explained to you the idea around docs demos and mentors and how to grow your open source tools across the world from my own experience um helping tools and fintech products grow across Africa. Thank you very

much. >> Thank you Mustafa. >> Do we have questions from the room? Please speak close to the microphone. >> Um hello thanks thanks for this nice talk. Um if I understand you correctly your basic idea is to involve the user community and uh let's say growing itself. Um is what what incentives are there for the users to become involved and and to mentor others? Do you have

a system in place like I don't know reputation badges whatever? >> Yes. Um very good question. So um your question is what incentives are there for those who want to become mentors right? So typically um as you grow in this every every layer badges should have um points attached to them should have um credibility attached to them. So what this means is that if you're a student,

you would the next stage um and that gives you much more credibility over the people behind you. For those that are mentors, it means that now they can be able to um they can be able to be uh maintainers of that product. They can join the governing bodies of that product. they also get um societal credibility to be able to run for positions. I am a leader

in this role or in this community and for that reason I can be able to do things right. So for each level and for each layer they are there are bad involved and each of the badges. So in other scenarios if you were um AWS or some other places they will say certificate right and you'll be able to qualify for those certificates to be able to get

to that next level. So just generally the idea is that for each level that you scale you have badges that describes you as that particular thing and gives you that credibility for way to to be a gives you the credibility and the and the credence to do things from that stage. Yes. Thank you. Do we have more questions? >> Welcome. >> Let me check if there are

any questions Thank you again for the talk and uh see you next year. Yeah. Heat.