Jan Dittrich – Best practices and (very) small projects #FOSSBack

This talk focuses on best practices for managing small open-source projects, particularly those with few contributors. The speaker begins by defining small projects as those that may only have one contributor and emphasizes their significance, as they can either remain small or grow with new contributors. They highlight the challenges faced by maintainers, who often work alone or in small teams, and discuss the limitations of traditional methodologies, like Scrum, which may not be applicable to such contexts. The speaker shares various practical strategies, such as using Kanban boards for task management and the 'tracer bullet development' method for building projects outward from a user interface. They stress that effective methods for small projects are often tactical rather than strategic, encouraging community collaboration to refine these approaches.

Hello. Um yeah, as I said, I'm uh Jan. I'm talking about best practices for small projects here. Um maybe uh starting with one question like um who is maintainer in a in an open-source project? Great. And who is like one of less than five maintainers that are active on that project? Great. Yeah, there are single maintainers. Okay. Great. Then I I know uh that that talk has

some relevance for the audience directly, I hope. So, the talk is um for anyone who helps peers to get better at their craft and also for people who struggle with working in the right way, whatever that will be. Um since the talk is titled um best practice in very small projects, what are very small projects? And we jump back. Okay. Um and why do they matter? first

of all, maybe sort of as a working definition here, uh with small projects that I talk about here, I mean projects that are open-source software um that have few or only one contributor and that are cared for. So, it's not like throwaway code that you put on a gist and then it just lies there. Um and small software can be very important. since uh on one hand,

like the small project might grow um and get more contributors if people are interested. Shout out to the hair talk um earlier this day. and also projects might stay small, and that is also okay. Um probably most of you know that comic Um like um a project some random person in Nebraska has been thanklessly maintaining since uh 2003. um that is no outlier. Um very many open

source um projects use um code that is maintained by hobbyists. And now you would say like, "Okay, hobbyists um like people who are not paid for that, who do that like in 1 or 2 hours a week. Um that is no problem. Like early Linux was hobbyist code, but that doesn't mean there's no collaboration. Um but if you look at that diagram by Josh Bracha, um these

are um counts for collaborators on GitHub packages connected to NPM, NPM the standard repository for JavaScript packages. Um what do we see here? The collaborator counts on the 13,000 most popular GitHub repos, those are the ones with more than 1 million downloads. And the project with just one collaborator are almost as many in those sample as all other with more collaborators combined. So, that is quite a

big amount, I think, and thus Josh Bracha says, "Open source is one person in very many cases." So, if you were one of those people who showed their hand, you're not in the majority, but almost, at least according to that uh data set there. and that is important to me also personally aside of my job at university as wissenschaftlicher Mitarbeiter in media ethnography, um I do some

um coachings and I consult smart projects via an agency called Superbloom. Um and that is supported via the um Prototype Fund grants. So, the projects get some support. They are sometimes one person, sometimes several. Um and I try to coach them on improving their UX design, their documentation, their code. Um and for this know-how, there's one challenge, um which is like most methods that you can read

about, that you find in books, that you get at told about about at the conferences like this one are for larger projects. Um like just some examples, not singling them out as any bad methods. I like both. Um just as an example here, if you look at Scrum, uh a method explicitly for small teams, um you need at least two supporting roles, and then you have one

developer, but probably you want more, otherwise you have two people supporting that one developer. Um so might have a team of at least five people working with Scrum usually. Um that is already like a group of people you need to pay for to get together. Um it's five more than on a lot of open source projects. Um closer to home maybe that, um a book that I

really love about face on user research, um that sort of codified the method of personas, and suggested team of two designers per user interview, and quite a lot of um interviews. You can do different calculations how many you need, but that is probably also more than a person sort of as a hobbyist maintainer um can do. I think that is really helpful. I worked according to that

method. I'm not pointing that out as unusually difficult or whatever. Um it's too difficult and too hard to pull off for most projects I coach at least. Um so there is infrastructure for working in the right way. Like you have team size, you have budget, you have buying, using the right tools, and like for example, if you employ a designer, you want that designer to work usually

like 50 or 100%, but not like 10%. Like you need enough expertise work for them to Um and those things are very often implicit in methods. Like usually people don't come there and say like okay, don't use that method if and then and get an elaborate intro on that. question, why is that this way? Like, who makes the methods? And with that, um I'm going a bit

to my uh academic home turf. Um here sociology of professions. Um this is the question like who suggests the methods, who gets to build those and on one hand, this is obviously like fame, who gets invited, who gets asked to write books, but it's also related to the structure of profession and assignment of professional prestige. Methods are usually suggested by people with professional prestige, those have the

resources to spread them. Uh those people usually work in big organizations or as consultants for big organizations. Um also because those are the contexts in which people can carve out niches to do the work, to develop methods and write books and so on. this means that there needs to be this this context and also very interestingly, like people usually avoid talking about compromises regarding their profession in

those methods because those are in all professions not seen as professional. Um a good example is I think uh GP, which is probably sort of the most important doctor in most people's life. That within like the professions of people who studied medicine is relatively low in prestige, also because the GP like in German uh the Hausarzt is confronted with a lot of problems that are not interesting

medically. It's like old people being worried about that something is hurting them and it's actually hurting them and it's important to talk to them, but they won't get fame from their colleagues for that because it's just the people are old, like things are hurting. and very often they can't do anything about that. And like a neurosurgeon rather has far more prestige. Like they don't get those professionally

not prestigious questions that are not connected to that discipline. um building in sort of compromises in your methods lowers your prestige in a sense or like puts you in a position where you need to defend that, why why you act unprofessionally. Um very interesting paper here, Andrew Abbott's status and status strain in the professions. Um excellent read. Um that is sort of the theory um I try

to build that on. So professional prestige isn't defining like pure strategies, but very many professionals need what I would call here tactics. Like these are the stuff that also the single maintainers or small teams of hobbyists could apply to their work and which are also very relevant if you work in a larger organization, but maybe in a smaller team that just tries something. so it doesn't mean

that you are in one position and then never get in the other. I tried to list some advice I like to give. And because this is as I said not a strategy, but um like just some things that that are helpful in the coachings I do, they don't follow a coherent framework. Like this is not the Jan method in anything, particularly because that would need that coherence

that needs a certain context and a certain prestige to pull that off. Um but that doesn't mean that those methods don't get written down or hard to access or are some like secrets that are rarely spilled. Um so these are some of the books that I that I really like, like classics in the field, probably nothing new. I point those out because those have some things in

common. Um which I will get to later um that many sort of books that emphasize one single method don't have. just going through my personal favorites here that have been most useful for small projects is tracer bullet development um from the book Ship It, it's also in the pragmatic programmer and comes with the like the very basic rule of thumb that if you collaborate in any project,

you should build outside in. Very often people start building inside out, like starting with the abstractions and then building towards the API. Um but the method clearly suggests like you first start with the with the interface and then you push your mock data further Um this way you always get a system that is working even if just with mock data and um side effect of me being

UX designer, you also get a system vertical that runs. Um and that is really nice if I want to show it to users. So uh also nice for collaboration with designers. Um another method that I sometimes uh recommend when um small teams trying to coordinate or just single people um trying to manage their time better. Kanban boards also not by any way any secret tip. I really

like that because it's a visual tool and uh you can use that for all interesting things. If you like go deeper in the theory what you can use Kanban boards for, like increasing velocity, reducing work in progress and even finer details of that. You can also use that as a glorified to-do list which has the nice side effect of being public. So it's a tool that really

nicely sort of scales up but that is also really easy to use um even for self-coordination. Another thing my work as a designer is like user testing. So, there is like a method called guerrilla testing where you sort get like go in a cafe and then like ask people to join your test that you don't know. That is sometimes ethically a bit um tricky. Also, you need

to be super extroverted. This thing is sort of more of a thing that I learned from like hanging out with people who design games. They usually have a laptop with them or a phone on which they have their running game. And if they meet with colleagues, they just like and you inevitably get the question of like what are you working on at the moment? And they are

usually like, "Oh, yeah. Try what I'm working on at the moment." And they collect feedback. As a UX researcher, I know that there is like quite some feedback you can't get with that method. It's like any testing method has like their pros and cons. That is a very easy one and there are a lot of games that are improved immensely by like talking to peers and just

trying things out regularly. So, um that seems to be a really neat method. Last but not least, something I noted when like working with open source projects, there's very often when designers come in, there is this idea of design being prototypically doing like changes about interaction and visual appearance. Um what often gets overlooked that reviewing strings for usability is really easy because those are usually like in

one file and they can be changed without going into any conflicts with the developers who then sort of need to be suggested, can you change this? Can you put in another like UI? Um this is a like relatively recent example from Inkscape where they just started changing in um here. It's like insert note at min X uh will be replaced by at note to left. Um like

we don't need to understand what exactly that interface does, but I think it's um fairly clear that min X is probably less intuitive for most people who don't know the code behind that than at note to left. those things that turned out to be useful for me in working in small projects myself or consulting small projects have those commonalities that they are usually coming as tips, as

rule of thumbs, and as how-tos instead of methods and frameworks that demand like a large group following them coherently and thus also a lot of power for getting them introduced. Um some of those books that are I showed earlier are also written for people whose main job it is not to be for example a UX designer, but who need to do that on the side. This was

particularly the um Apple um interface guidelines and Don't Make Me Think, um particularly written for that target group. So, like when you go sort of out of the core of the profession, you sometimes get more of those um practical small project compatible tips. Um I think and they make few assumptions about particular infrastructure or resources. A lot of them work for a single person. Um and then

if they are n- neat, they also like can be scaled for a team as like for example using a Kanban board or like structuring your own code writing by using sort of this outside-in method and pushing the mock data in tracer bullet development. So, uh summary and outlook. Um So, um methods often assume resources that um many people don't have. Um and that mismatch is explainable by

the way professional prestige is assigned to people and who gets invited to write books and speak at conferences. Um, applicable um, ways to work for smaller projects um, are rather tactical than strategic in many cases. what can you do is obviously um, taking part in that professional exchange that as a community find describe and share and refine your ways of work. Um, particularly the parts that are

not large-scale strategies, but locally applied tactics. And I think one historical example by now would be sort of the C2 Wiki in which a lot of like pattern-driven programming and Agile development have been originally developed in the mid-90s where professionals exchanged about their ways of work. So, uh, I think that is still a great model um, for collaboration and developing our professions for bricks big strategies and

tactics alike. So, THANKS A LOT. WOW. THANK YOU. THANK YOU, JAN. SO, right now we've got the time for questions and answers and your comments. So, who's going to take the mic for me? So, thinking about the cyber resilience act and some of the things we've been talking about this week, do you think there are ways that bigger foundations can offer targeted support to assist in the

the training and the tactics rather than just saying, "Here's a giant strategy you can't follow." I think yes, that can be done. I I would assume that might be difficult to finance because as said like it's less of a coherent thing that can be offered. But, um, I think up like broadly speaking like opportunities for practitioners to meet and be supported in doing so like in travel

grants and working groups um could help. And also I think there is a lot of like learning material missing that are very much like those guides that I showed initially particularly sort of in the open. It's very hard from writing such books like it needs a lot of work it needs editors and so on and I think like a lot of those tips are out there but

they are not brought in a form that they are very easily accessible and this could be also projects that can be supported in getting people in those positions as single maintainers together collect those things and then have them professionally edited and made accessible to other people in the same situation. Okay, you got me curious about the those rules of thumb and do you have any particular rules

of thumb that you found that work in open source but don't work outside of the open source and vice versa? I think I don't have any rules that only work in open source that are not like well known I guess. There there are obviously sort of um rather be proactive and a lot of like practices that are very common like first file an issue then try to

make a pull request and so I think they're that much in the culture of open source projects that I probably found more interesting things that I uh had sort of an epiphany about about programming and design in also that those fields are very much more sort of structured along the lines of professional prestige that there was a lot of things where I sort of ran into walls

and then we're like, "Ah, okay. This is why people suggest and there are also methods to do it in a different way." And I guess that's why we've got the day dedicated to design tomorrow. Yes, we do. And uh I will be there and uh would be looking forward to interesting exchanges about your experiences. Well, it's just a question because of some previous presentation about um documentation.

And I think this maybe it's also something that could fit in this toolbox. the guy presented just easy to follow well, what is your um project for, who is supposed to be here. And this should be part of the readme and the contributing. So, are these options that could also be taught as tactics? It just clearly states it's a one-person project and I don't want to have

you around or it's just something that I'm doing on my weekends. Would this also work? I I think that would be actually a a really helpful thing to like clarify expectations there because I think a lot of like the the implicit value sort of yeah, like you we want sort of large projects that are probably have the um like the Linux kernel as their implicit model. But

many projects work in a different way like uh interestingly sort of Git and Linux kernel uh and and the Linux kernel as Torvalds' projects and there's also like SQLite and Fossil that are very much like developed by a very small team which clearly says like we're not interested in drive-by contributions. And I think like clarifying those things are really helpful because that prevents maintainers being overwhelmed by

um like help they actually don't want and from people who like put in the pull requests and then are disappointed that people don't act on them. So, yeah, I think that's a great idea. So, the rule of thumb which is not different from any other thing is like don't burn out. But the what is special to free software is that remember that I offer something but I

don't make any promises. And so always keep that in mind that it's totally my decision how much time I'm going to spend on this so I can be in a state stay in a state to actually maintain the software. Yeah. Do you have any tactics for AI slope? Yeah, but tactics for Now first left and right. Part of my UI advice, the book I showed is from

the early 90s so I might need some more time for that. No, probably nothing that that not anybody else doesn't know like yeah, put like in a project I'm working on I put it in the read me and clarified the expectations of the project because that also makes it easier to say like no, I I don't accept that. Um, pull request for example because hey, here's here

are the rules. From my research experience, what do you think would lower the barrier for specially small projects and we haven't talked about numbers like lines of code but how can we encourage even small projects to document their architecture and uh maybe visualize their architectural design? I think it's a really good question for which I don't know a good answer because I also know that most big

projects don't do that. And whenever I try to read source code of projects I'm new to, I'm looking for an architecture documentation and I usually don't find it. Um so, hey my my it's not a tip or rule of thumb, it's just an appeal like please document your architecture. It's so helpful for beginners. Please, but really please document. Really loud applause, please for Jan.