DEV Community

loading...
Cover image for Working in Public: how can we solve the problems of open source?

Working in Public: how can we solve the problems of open source?

emma profile image Emma Goto ๐Ÿ™ Originally published at emgoto.com on ใƒป5 min read

Nadia Eghbalโ€™s recent book Working in Public: The Making and Maintenance of Open Source Software, covers what the open source experience is like for maintainers today.

It ends with the following sentence:

โ€œWe donโ€™t have all the answers yet, but Iโ€™m hoping this book helps point us towards the right questions.โ€

This felt like a very apt conclusion, for I did walk away from this book feeling a lot more sympathy for those who do work in open source, but also without any real answers or solutions for what we can do about open source.

This post is a summary of some of the things I learned from Nadiaโ€™s book. At around 250 pages itโ€™s not too long of a read so I would definitely recommend buying the book for yourself if you have any interest in this topic.

The open source community has grown friendlier, and more inclusive

Eghbal points out that open source has come a long way in becoming a more open and inclusive community. Repositories now have codes of conduct, and there is a culture of being generally welcoming and friendly towards first-time contributors. This contrasts with the earlier โ€œbenevolent dictatorsโ€ of open source like Linus Torvalds (the creator of Linux) who in 2018 apologised for his many years of "unprofessional and uncalled for" behaviour.

Iโ€™ll admit gave me a chuckle when I turned the page to see Torvalds giving the finger, juxtaposed with Sindre Sorhus surrounded by Huskies:

Github is also credited for reducing the barrier to participating in open source. Since we have standardised on Github as the place most open source repositories live, this means users are more likely to be familiar with the interface (and to already have an account). This makes it a lot easier for users to open issues when they encounter bugs or have questions, as well as to raise pull requests to fix these bugs or add new features.

Popularity can lead to maintainer fatigue

The generally welcoming nature of open source combined with the ease by which users can create PRs or issues can result in a lot of work for maintainers (especially those who maintain a repository by themselves). They may feel pressured to respond to every issue and pull request received, and to spend time helping contributors to get their pull request to a state where it can be merged.

Of course, not all contributors are a burden. It may be that by taking the time to help a first-time contributor merge a pull request, they could go on to contribute more useful pull requests in the future. But if more than 50% of contributors are one-off contributors to a project, that can be a lot of time invested by maintainers that they're not going to see a return on.

This pressure can cause some maintainers to want to quit. However even quitting can be hard! Deleting a popular repository could โ€œbreak the internetโ€ as was the case with left-pad. And finding someone to take over your repository might mean needing to put your faith in a relative stranger, who could end up adding malicious code to steal your Bitcoins.

Should open source be a one-way mirror?

One of the potential suggestions Eghbal poses to this problem is to make open source a one-way mirror. In practice, this would mean that users would be able to see the code, as well as any discussions that maintainers are having, but would no longer be able to open pull requests or issues asking for help.

Maintainers would be able to opt-in certain contributors who they know would bring value, or they could allow people who are sponsoring their project access as well.

This would drastically reduce the amount of time maintainers have to spend responding to usersโ€™ requests, and allow them to do more high-value work.

With the inclusive and welcoming nature of open source, there could be some anger directed towards maintainers who take this approach. I think it would be too drastic of a change to be widely adopted any time soon, but I think there's a lot of inspiration we can take from this idea. Maybe there's some sort of middle ground?

Looking for solutions

Eghbal has pointed out some of the problems plaguing open source today, but given this is a very hard problem to solve, understandably there are no perfect solutions yet.

To some extent, we can mitigate some of the busywork maintainers have to do by using bots and other automation (like running tests when contributors open PRs). Maintainers can also uphold a certain set of standards that a pull request must meet before it becomes reviewed, and provide clear documentation to help first-time contributors meet these standards.

Maintainers could also employ curators who could maintain a similar role to what moderators do on Twitch - weed out any low-value issues or pull requests, and surface to the maintainers only the issues and pull requests that are worth the attention.

As Github is the platform of choice for open source, maintainers are also reliant on Github to provide the features they need to work effectively. For example, users can now vote on issues by using the โ€œthumbs upโ€ emoji, but for a long time this feature was not available, and so maintainers had to deal with receiving notifications from users leaving โ€œ+1โ€ comments.

Conclusion

As someone who has dabbled a little bit in the open source community, Working in Public has provided me with a lot of food for thought, and definitely makes me more sympathetic towards maintainers!

The book feels especially relevant this month with Hacktoberfest which has unfortunately caused a lot of difficulty for maintainers of open source projects.

I'm interested to see what direction the open source community takes into the future. I think the idea of curating issues/PRs on repositories (similar to Twitch moderation) could also be a great way for people to start contributing to an open source repository if they don't feel comfortable enough with the codebase, but want to help out.

Maybe there's some way we can crowdsource this and create some sort of platform so that maintainers can ask for help curating, and volunteers can step in. Could be interesting!

Discussion

pic
Editor guide
Collapse
brandelune profile image
Jean-Christophe Helary

Thank you for your interesting comments.

It seems to me that the reason for most of the issues the author discusses comes from the fact that even though "open source" wants to look like a cool thing, it is just a development model that has been coopted by some free software developers to make free software look less "scary" to the business world.

"Open source" was never intended as a process to share values and I think that is the original "sin" of "open source", and that is where all the above issues stem from.

Free software is a political and social movement that aims at freeing users and developers. Free software is not a development model that aims at productivity and inclusion of "business" thinking. So when you take that perspective, you see that a lot of the issues above (not all of them) are moot.

If you want to see what I mean, take a dive into the emacs development list. Emacs, as you know is the free software movement flagship. Its development list is an amazing place that is extremely busy and discusses all sorts of things (not all related to code per se), but it never loses focus because the point of the list is not to provide efficient discussions about specific technical aspects of the work but to see that developers and users share the same consciousness of what freedom in code means.

"Open source" reminds me of European socialist parties from the 80's. When they saw that class struggle was not fashionable anymore (and required quite some actual organizing work), they decided to shift to "societal" issues, like race/gender discriminations. And they utterly failed at solving those issues, because at the core of such discriminations is the broken social contract that keeps being forced upon us.

Collapse
emma profile image
Emma Goto ๐Ÿ™ Author

"Open source" was never intended as a process to share values

Since I wasn't really aware of the "free software" distinction I did a bit of reading. When you're talking values do you mean how open source today has these values of being "nice" and exclusivity? Do you think we should be swinging back towards the more "mean" approach?

Collapse
brandelune profile image
Jean-Christophe Helary

Not "mean". I really mean that "open source" was then a way to sell free software to businesses that wanted to benefit from "free" (as in beer) developers. It had no specific moral values attached to it.

Now, communities have grown more diverse and some rules have to be set, but to understand the current issues it is necessary to go back to the origin of the phenomenon. At the time, Microsoft talked about free software in terms of "cancer", "virus", "communism". Those were (and still are) very loaded words. And Microsoft attacks were that virulent because of the strong principles that animated the free software community.

When you remove those principles and just leave the licensing scheme, add a marketable term and some famous people to co-opt the movement you get to the point where "open source" becomes a cool entry point for new-comers without any commitment to moral values (which is not bad in itself, and also exists in free software). And at one point you need to make sure that everybody is nice and inclusive, because it is the right thing to do, but also because there are big economic interests involved. Look at Wordpress for exemple.

So, to go back to my original idea, I think it is easier to convince people to do the right thing (not only in terms of behavior, but also in terms of participation) when the movement is based on strong values than when it is not. But I may be biased because I prefer systems with strong values than systems with weak values. It makes for an easier choice.

Thread Thread
emma profile image
Emma Goto ๐Ÿ™ Author

Thanks for the explanation!

At the time, Microsoft talked about free software in terms of "cancer", "virus", "communism".

Wow, funny to think they used to think that way and now they've acquired Github!

Thread Thread
brandelune profile image
Jean-Christophe Helary

And they are also integrating Linux in Windows with WSL, so their strategy as considerably evolved, and the reason is probably that they can appreciate the potential of taping into an almost infinite pool of talented coders. But I'm not sure that changes their motivations one slightest bit.

Collapse
sramkrishna profile image
Sriram Ramkrishna

Being part of a free software project for 20+ years and close to that enthusiast crowd who use Linux on their desktop - the challenges are interesting and take on another dimension when working at the consumer level.

Great post - thanks for sharing.

Collapse
emma profile image
Emma Goto ๐Ÿ™ Author

Thank you! To be honest I wasn't really aware of that distinction between free software vs open source - something I need to read up on.

Collapse
sramkrishna profile image
Sriram Ramkrishna

The difference is open source is a software development model that has a social contract with the community to socialize the cost of development by being more open through an open source license.

Free Software is a social movement that believes that the source code should be available to all - based on the 4 freedoms:

I used to ask this as an interview question :D

Thread Thread
brandelune profile image
Jean-Christophe Helary

Sriram, I'm pretty sure the OSI does not defines open source the way you do.

opensource.org/osd

Open source originates in free software and can't be "more open" than free software (I know that's not what mean, though).

There is no social contract with any community since open source exists only as a way to have businesses use free software without focusing on the freedom.

The OSD is based on the "Debian Free Software Guidelines" which are part of the Debian Social Contract. But you don't find any reference to a social contract in the OSD or anywhere else on the OSI pages.

debian.org/social_contract#guidelines

Also the free software movement does not "believe" that the source code should be available to all. It makes the source code available to all because that is the precondition for bringing freedom to software users. That's not a belief, that a practice, and the FSF actually commits itself to fighting for user freedom, which is a social contract that the OSI will never endorse.

The same Microsoft that used to want to eradicate free software (and open source, at the time), now owns Github, one of the biggest free software development hub in the world.

When the company bought Github the move sent a chill through the whole FOSS world. It's like the fox buys the henhouse and promises to play nice with the chicken. As Emma correctly assesses, development processes are tending to standardize on what Github does, and honestly I find this utterly scary.

Thread Thread
sramkrishna profile image
Sriram Ramkrishna

When I am using social contract - I'm not referring to any guidelines or anything - just the use of an OSI approved license is the social contract that's why I added the license. By using the license, you're saying I'm going to open up my code so that you all can participate. I'm not using a formality as defined by Debian Social contract.

But your comment does not invalidate the difference between Free Software and Open Source - Free Software is a social and political movement - Open Source is not - it is a method of collaborative engineering that involves the programming and non-programming public.

Thread Thread
brandelune profile image
Jean-Christophe Helary

Free software too involves the programming and non-programming public. And that's the whole point. Users are defined as actors in the free software movement, not in the open source development model. As for user licenses they are not "social contracts," they are, well, user licenses, which is an individual contract between a licensor and a licensee.

All that I am saying seems like, and probably is, pointless bickering. I'm honestly happy that people who endorse and participate in "open source" (and name what they do that way, instead of "free software") feel like they participate in something that is bigger than them and is used to better society.

Just back to the original point developed by Emma, I think that a lot of issues encountered by the "open source" movement stem from the fact that it is something that started without a clear value set.

It is good to see that when you reach a critical mass, you need to add values, but "being nice" and "being inclusive" are not "values," they are "protocols." The sooner open source people realize that, the better.

Did you know that emacs development is always concerned about how new code impacts performance on low spec machines ? Fighting for user freedom means that you must ensure that your software runs on very low spec machines, and by doing that you ensure that the machine does not waste too much energy and that is also good for the environment, which is an extension of user freedom.

Having a nice and inclusive open source development process does not automatically lead to produce such outcomes, and, of course, all free software does not go that far, for practical reasons (human resources first, access to test platforms second, etc.) but I hope you understand what I mean.

Thread Thread
sramkrishna profile image
Sriram Ramkrishna

I'm familiar since I am part of a Free Software project - GNOME and have been for 20+ years. So being able to use a machine from use older machines and still make them useful is a great thing and actually reduces our carbon footprint - feel free to check out what my employer is doing in this regard (see the blog series I'm writing)

Collapse
bhupesh profile image
Bhupesh Varshney ๐Ÿ‘พ

In practice, this would mean that users would be able to see the code, as well as any discussions that maintainers are having, but would no longer be able to open pull requests or issues asking for help.

SQLite for example have been following this model for soo long, you can't create any PRs but contributions can come in form of bug-reports, etc
Can't say if it's effective for the long term or not but hey we see its clearly possible

Collapse
brandelune profile image
Jean-Christophe Helary

SQLite is probably the most used and resilient database software in the world, so that's a proof that the system works.

PRs are just a device. Before Github existed there were no PRs and before git existed collaborative work was much more restricted because branching was not trivial. PRs (and thus Github) have added a huge lot of "bazaar" to the development process, but git based development does not have to be like this, and is not in most important git repositories.

Collapse
emma profile image