I’m curious to hear people’s thoughts on what principles open source projects should adhere to in order to promote transparency, inclusiveness, and effective development. Are there any specific projects you feel do a great job following certain principles in how they operate? I’m interested in how projects organize decision making, manage donations, incorporate community feedback, communicate updates, and more. Please share projects you appreciate for how they approach open source development!
I feel one of the most important things for a thriving open source project is easy onboarding.
Statement of friendliness and similar are not that useful if I don’t know where to start to contribute to your project. A clean, up to date
CONTRIBUTINGfile goes a long way, architecture documentation is extremely good, optimal is having an experience developer checking your patches and offering help.Repositories that I contribute to the most helped me in the first phases of the journey, it was awesome, I gave back.
Dude, please take this with all the kindness in the world, but to me it looks like you asked some questions yesterday about contributing to Lemmy, you got answers you didn’t like, and now you’re asking the exact same question in a much more indirect way in hopes of steering the conversation back to what you want to hear and how you like to look at it.
I and the other people who gave you answers before are trying to help you be more successful with your contributions. We’re not trying to criticize or put you down or anything. I might be right or wrong about this or anything else, but I think it’d be to your benefit to slow down and really listen to what people are saying and how you can contribute in a good and productive give-and-take way, instead of just making your list of demands for how everyone else needs to be.
Or not. It’s up to you; just that’s my recommendation based on my limited knowledge of the situation.
Just to be clear, it seems you apparently deleted the much downvoted posts you made here and on [email protected] where you called for forking Lemmy because you claimed the maintainers were acting akin to tyrants. You said they were closing issues and rejecting PRs that users wanted to see because the maintainers themselves didn’t want them. When asked for examples, the only examples you came up with were:
- A weirdly annoyed contributor closing his own PR, followed by the maintainers of Lemmy fixing the PR themselves and merging it within days.
- An issue open since 2020, where a maintainer commented that he didn’t think it was a priority or a necessity, and when pinged about it again this year, made it very clear that he was open to a PR to add the requested functionality.
Do you still think Lemmy is run by tyrants? I find this post a bit jarring given the context of your previous one.
The only thing that I’ve seen the developers say in GitHub comments is things like we are busy and don’t have time for that. And that is after saying this:
Before opening an issue, make sure that it hasn’t been reported before. And when writing comments, make sure that they actually contribute to solving the issue at hand. Generally it is better to move discussions to Lemmy if possible. We are very thankful to everyone who contributes by writing code, hosting instances, moderating communities, and answering questions.
— Originally posted by @[email protected] in https://join-lemmy.org/news/2023-06-17_-_Update_from_Lemmy_after_the_Reddit_blackout
I don’t think they are tyrants but they are a bunch of hypocrites.
I don’t care that much about those examples, what I really care about is them not following what I consider to be some important principles when it comes to open source projects.
-
Clear Decision-Making Process for Future Releases: Open-source projects should have a well-defined process for deciding what features and improvements make it into each release. This process should be documented and accessible to the community. (For example, you can read about how Discourse decides what goes into each release here). Discourse, for example, follows Complaint-Driven Development.
-
Transparent Donation Management: Be open about how donation money is allocated. Implementing a bounty system can further enhance transparency, enabling contributors to work on specific tasks for financial rewards.
-
Inclusive Community Involvement: Encourage active participation from the community in brainstorming and voting on potential features before finalizing the project roadmap. Community input can be invaluable in shaping the project’s direction.
-
Beginner friendly: Make the project welcoming to new contributors with clear documentation and mentorship.
-
Public Roadmap: Maintain a publicly accessible roadmap that outlines what is planned for upcoming releases. This roadmap should include the status of each feature or enhancement to keep users informed.
-
User-Friendly Feature Request Process: Provide a public feature request forum where users can submit their ideas. Clearly outline the process for how these requests will be reviewed and prioritized, ensuring transparency in the decision-making.
-
Effective Communication Channels: Avoid using disorganized or private communication platforms for project-related discussions. Instead, opt for well-structured, publicly accessible channels that don’t require users to log in to access information.
-
Document with a Blog: Utilize a blog or similar documentation platform to keep users and contributors informed about important project updates, changes, and developments.
It is their project, their code, their processes. They do what they want. I hate when people tell me what to do on my own projects.
GitHub (and the others) are more inclusive than ever: free to fork, free to work.
You’re describing and demanding additional work that takes time, and that they may not want to do at the time. If you want it, fork it and do it since it’s free for you.
I don’t think they are tyrant but they are a bunch of hypocrites.
Was this bit meant to illustrate hypocrisy?
The only thing that I’ve seen the developers say in GitHub comments is things like we are busy and don’t have time for that. And that is after saying this:
Before opening an issue, make sure that it hasn’t been reported before. And when writing comments, make sure that they actually contribute to solving the issue at hand. Generally it is better to move discussions to Lemmy if possible. We are very thankful to everyone who contributes by writing code, hosting instances, moderating communities, and answering questions.
Originally posted by @[email protected] in https://join-lemmy.org/news/2023-06-17_-_Update_from_Lemmy_after_the_Reddit_blackout
There are 217 people who have contributed to LemmyNet/lemmy. The people in charge are the original authors and maintainers, but they are not the only developers by a long shot.
As you seem to be aware of in the rest of your comment, open source projects like lemmy are sustained because when issues are raised, community members contribute to the project to solve those issues. It’s entirely reasonable and often expected that project maintainers are picky about which issues they personally take on. That doesn’t mean they are rejecting the issue, it just means they won’t personally be writing the PR for the fix anytime soon. I see no issue there.
when writing comments, make sure that they actually contribute to solving the issue at hand
The only thing that I’ve seen the developers say in GitHub comments is things like we are busy and don’t have time for that.
Do I really need to explain to you what the hypocrisy there is? Rules for thee but not for me.
If they are busy they shouldn’t say anything, let other people contribute something actually useful to the issue at hand.
Maybe they could be a bit more explicit, but I don’t see hypocrisy.
Accepting your description of their comments:
I’m busy and don’t have time for this
is roughly equivalent to
I will not be personally taking on this issue, so if someone wants to contribute, this is a reasonable candidate.
which is good information to get from a maintainer.
I will say, however, the times they said something along those lines in the examples you gave in your last post, they also said why they didn’t consider it a high priority, which gives more important context as well.
Rules for thee but not for me
It’s normal that there are different rules for authors and bug reporters.
It’s like you’re complaining that there are different rules for guests and the owner of a house.
-
I like KDE in how they approach new users. There are some people like Nate Graham investing so much time into talking to stupid bug reporters like me.
Having the first “start contributing” link be a Matrix Group is also nice, instead of some Git instance.
Change my mind, but I think Git* is horrible for collaboration if you use it exclusively
Open source isn’t some special ordinance that makes a software project subject to any principles other than the ones outlined in its software license. The most basic principle being that someone wrote something which they thought could be useful for others and therefore published it under an open source license. If by releasing a piece of software I were strongly expected to adhere to any other principles like some of the ones you’ve suggested elsewhere, I wouldn’t have released half of the stuff I have because I simply can’t uphold these principles. Upholding them isn’t free. It requires work which I don’t have time for. I’ve already shared the work I was able to do by releasing as open source.
Edit:
I see a lot of confusion among what I assume is younger people who are relatively new to open source. Confusion as to open source being about freedom of choice, inclusion, democracy or what have you. It isn’t. Some open source projects may be about one or more of those things. Many, even possibly most aren’t. For example the Linux kernel is a hard dictatorship with Linus as top executioner. Convincing people of varying software engineering proficiency of why their favorite feature shouldn’t happen or why their PR is garbage and will decrease the quality of the project in various ways takes way longer than closing the respective item. GNOME is famous for “Closed/Won’t fix” with no explanation. Perhaps if open source developers were handsomely paid to spend the extra time to be nice, things could be different. Of course that implies that more developers must be paid to do the work since everything takes longer, or the pace of the project would be slower. Pick your priorities and pay for them appropriately.
I believe that building a community around the software is more important than building the software itself. I know of a project that, despite not being used by 48k monthly active users, has more than 217 contributors, which is what Lemmy has. I believe this is because they implement some of the principles I mentioned. If you don’t need software to be maintained then you don’t need a community either, so you can just disregard all those principles.
I like curl’s standard and trasparent release cycle. The consistent feature freeze before releases seems like a good idea to prevent bugs.
I’ll humor you and give my input. If someone is making a FOSS project, get at least one person on your team with rudimentary social skills. Make them involved with support. Because as a simple user, “just use Discord” or “just use Linux” is not an answer to a tech problem, and it can sometimes be insulting to have the go-to people avoid answering the question
