The Developer Playground
FLOSS projects constitute a very unique opportunity for developers especially. It embodies an environment where one can have fun, learn and create quality of life improvements to a piece of software that is being used in their everyday life. This however, puts design contributions in a tough spot in certain ways and is in many ways at the core of the complexity of this issue. How do FLOSS projects maintain this environment while creating better design decisions?
One of the motivational factors that was discovered in the interviews i have called “the developer playground”. Several of the contributors noted that they mainly were driven by fixing issues they themselves had with the product.
One contributor said that he “(…) I started with the intention to fix only a few things. However, after fixing something, something else appeared that I wanted to get sorted out.” (Interview, Jellyfin).
Usually these first engagements with a project leads to more down the road.
One developer said that he contributed in the beginning “(…) mostly out of personal needs. I was annoyed with some things at first, then it sort of evolved from there” (interview, Jellyfin).
Others noted that they had a lot of fun while “(…) contributing to Jellyfin and pushing my code in GitHub helped me realize that I wanted to go into software engineering.” (interview, Jellyfin). With the above in mind, it seems that a lot of the developers in the project are entering into FLOSS as,
- A way to empower their own private use of the software
- Learning new skills
- Having fun while doing so
These 3 things are key to “the developer playground”, and might aid in understanding why design contributions might not as easily fit into this context.
Jellyfin and Taskcafe in numbers
To further poke at this rather unique combination of elements, the contributors were asked about users numbers, as seen above, and whether or not they found those to be motivational, in and of itself. Here one of the participants put it as follows:
“I find them motivational but I don’t think it is the fuel that keeps me working on our project. We do this for fun, for the learning experience, because we use it. We have many reasons among the team”.
To summarize, it would seem that developers’ motivations in this regard are also very driven by the fact that FLOSS projects are a place that can support developer interests, give access to new knowledge while maintaining a no-commitment attitude towards the amount of work being done by each participant. This especially rings true when thinking about how software development in traditional organizations might be a solo activity as brought up by one of the backend developers of Jellyfin. This mindset also constitutes a departure from more traditional software development processes where software developers likely handle most of the execution and implementation, while the actual requirements for the software might come from a client, design team or some other organizational entity.
In other words, “(…) the ‘blank slate’ is very exciting” (Interview, Jellyfin).
With the above findings in mind it would seem to suggest that most of the contributors follow a similar pattern getting into FLOSS projects. First, a project is approached or even created to fulfill one’s own needs, learn, for ideological reasons or to simply have fun. Then as more people join the project the sense of community, cooperation and the resulting social interactions or team that is created form stronger commitments to maintaining the project. The idea that certain people might leave at different stages is supported by for instance what one of the contributors from the interview said.
He noted that “(…) usually the people that only care about some annoyances they have in their daily use do ‘hit and run’ pull requests. They fix or implement something they want, get it merged, then we never see them again.” (interview, Jellyfin).
This might also ring true with regards to the ideological commitment FLOSS projects can embody. People who only are interested in the “it’s free”-mantra might simply not be invested enough in this model for them to stick around and keep working on and engaging in a project community as suggested by the interviewees.
To summarize, it would seem that while a lot of the developers do voice their opinion that they surely are developing for themselves, as they are users of the software, it would seem that as a project goes on their invest in developing for others grow to be larger if not the largest factor when considering motivation forces in a FLOSS project.
Discuss
Summary
- There is a sort of duality in what developers say drive them to maintain FLOSS projects. 1) On one hand, developing for people and receiving appraisal and positive experiences seem to be very important as also suggested by previous studies. 2) However, on the other hand the developers seem to hold onto the fact that in the end are developing for themselves.
- Raw user numbers are less motivational than having fun and learning.
- This raises the question in wide user adoption is even a goal of FLOSS software. In any case it is a discussion worth having in your project. Are you trying to get a large user base? What motivates you?
- The design discipline seems to automatically be at a disadvantage in FLOSS as most who join FLOSS projects do so to fix, in code, some issue they themselves are dealing with. Design proposals are a totally different type of inquiry and often cannot be boiled down to a single button or ‘fix’.