What to expect from open source?
– spatie.be - submitted by Spatie
Read more [spatie.be]
Posts tagged with oss
– spatie.be - submitted by Spatie
Read more [spatie.be]
– gummibeer.dev - submitted by Tom Witkowski
This post is a response/reaction to "From Contributor to Maintainer: Lessons from Open Source Software" by Patrick Organ.
Read more [gummibeer.dev]
Join 9,500+ smart developers
Every month I share what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.
No spam. Unsubscribe anytime. You can also follow me on X.
– dev.to - submitted by Patrick
Lessons learned from contributing to open source software projects.
Read more [dev.to]
A nice lighting talk given by my colleague Seb at the first edition of Full Stack Europe.
My colleague Seb lists a few very good actionale tips that help you maintaining open source software.
In the 4.5 years I’ve been a developer at Spatie, over 200 packages have been built and released by our team. I’ve done quite some authoring and maintenance over the years, and I’d like to share 8 actionable tips on writing and maintaining open source software without going insane.
Read more [sebastiandedeyne.com]
The issue of whether there is a generalized sustainability crisis in open source is a contentious one, but that doesn’t obviate the need to find a solution for open source projects that do struggle to find funding and volunteers to support development. Whether these are marginal examples or a rising epidemic, the fact that they continue to work on open source projects in spite of this shortcoming is a testament to their dedication to the goals of the project and open source development more generally. Yet most developers are in agreement that if there are ways to sustainably fund the open source community, this will ultimately lead to even better software.
Read more [motherboard.vice.com]
James Long gives some solid advice: always keep in mind that there are a lot of things that are more important than coding.
The goal of free open source development is empowerment: everyone can not only use code for free but also contribute to and influence it. This model allows people to teach and learn from each other, improves businesses by sharing work on similar ideas, and has given some people the chance to break out and become well-known leaders.Unfortunately, in reality open source development is rife with problems and is ultimately unsustainable. Somebody has to pay the cost of maintaining a project.
Jeff Geerling, currently working as a technical architect at Aquina, wrote a good post on when and why he closes PRs to the packages he's maintaining. This paragraph resonated with me.
I don't cater to everyone. I usually cater to myself. And for 98% of my OSS projects, I'm actually using them, live, in production (often for dozens or hundreds of projects). So I'm generally happy with them as they are. I will not add something that increases my maintenance burden unless it's very compelling functionality or an obvious bugfix. I can't maintain a system I don't fully understand, so I like keeping things lighter and cutting off edge cases rather than adding technical debt I don't have time to pay off.
http://www.jeffgeerling.com/blog/2016/why-i-close-prs-oss-project-maintainer-notes
Without any doubt Tim Wood, the creator of the awesome moment.js library, has done a lot for the community. It's really a shame that the constant pressure of maintaining the library has taken it's toll.
The correlation between Open Source and burnout is no secret, and I am not immune to it. ... Seeing bugs and issues continue to roll in and being mentally unable to address them has led to feelings of failure and depression. When looking at the moment project, I could only see the negatives. The bugs and misnomers and mistakes I had made. It let to a cycle of being too depressed to contribute, which led to being depressed because I wasn’t contributing.
Michael Bromley on his blog:
http://www.michaelbromley.co.uk/blog/529/why-i-havent-fixed-your-issue-yetThere is an implicit agreement which needs to be understood by both consumers and creators of FOSS projects1. It goes something like this:
- I agree to provide you with some free code which solves your problem.
- I recognize that in doing so, I have taken on a small portion of responsibility to you as a user of my code.
- I agree to try to help you if you have difficulty in using my code.
- I agree to try to fix bugs that you find in my code.
- Crucially, you agree that I, in acting without remuneration, am free to assign priority to the above points as I see fit.
The last point is the reason why I haven’t fixed your issue yet.
As a package consumer you should be grateful for the free code you're given. Keep in mind that when you use someone else's code, you are responsible for that code as well. If a package maintainer solves an issue for you that's great. If he or she doesn't, than that's your problem, not the maintainer's. You can always submit a PR with a fix. And if the fix or feature doesn't get accepted you can always maintain your own fork.
For our own packages we try to respond to every single issue in a timely manner. The users of our packages are generally very friendly and helpful. There's only one instance when things went sour. I do make a point of thanking everybody who takes the time to submit a PR. It's a small thing but I do believe it helps creating a positive vibe on our GitHub repo's.
The slides of a talk by Jordi Boggiano (of Composer and Monolog fame) on maintaining OSS projects.