Someone starts a new #FOSS project as a hobby activity.
-
smallcircles (Humanity Now π)replied to smallcircles (Humanity Now π) last edited by
I am sorry people. There are too many replies for me to respond to them all. Please check other branches of the discussion as your question may already be addressed there.
-
Nemoreplied to smallcircles (Humanity Now π) last edited by
@smallcircles
I think the tension is that you built a public project, invited the public to partake, but somehow never meant the public to participate meaningfully (including governance).I think that if you have a hobby project, it's fine. But if you want to *build* an open source project with no thought about governance, you're doing it wrong.
Exception: you *really* want it to grow and approach hobbies like work. Then BDFL can work for a while.
@mir -
smallcircles (Humanity Now π)replied to Billy Smith last edited by
@BillySmith @laxla Thank you!
There's a lotta info around. I'm seeking best-practices to include in something of a pattern library to pick'n choose from.
Inspired by this whole discussion I just formulated one myself:
> "Expected behavior in the #CodeOfConduct of a #FOSS project should be aligned with a #StatementOfCommitment by those having ownership of the project."
I may bring that to a post at #SocialCoding movement https://discuss.coding.social
See also: https://social.coop/@smallcircles/113508224930993093
-
Dawn Ahukannareplied to smallcircles (Humanity Now π) last edited by
@smallcircles @jenniferplusplus
Someone who chooses to handmake arts & crafts (good & cheap) is not called BDFL because they canβt physically & financially make quantity to meet βunpaidβ demand & expectations.
This is a βsupply & demandβ economic & power dynamics problem masquerading as a software technology βcommonsβ problem.Good, fast, cheap ven diagrams(truth table)
- Good+fast = expensive
- Good+cheap = slow
- Cheap and fast = low quality
- Good + fast + cheap = impossible (expectations) -
smallcircles (Humanity Now π)replied to Peter Toft JΓΈlving last edited by
@joelving sure. And I understand and even agree to most of the arguments made in this entire thread.
At some point frictions are 100% certain to emerge, and also - in majority of cases - not dealt with in an optimal way (not say, often handled badly).
We need good/best-practices for mitigating risk of unaligned expectations and lay the basis for a healthy and well-understood governance model (if where that model's theme is "Hobby Project").
Here's my wood chop analogy: https://social.coop/@smallcircles/113508151463049043
-
smallcircles (Humanity Now π)replied to unexpectedteapot last edited by
Yes, there may be a tipping point where that statement is perfectly valid and justified. But when that happens is not clearly defined. There is a gradual shift in the social dynamics in the course of the project's lifecycle.
(I use the notion of a Free Software Development Lifecycle or #FSDL for this, that can be explicitly reckoned with in the dev process)
See my analogy and follow-up best-practice idea to help mitigate the issue: https://social.coop/@smallcircles/113508151463049043
-
smallcircles (Humanity Now π)replied to Laxystem last edited by
The crucial word in your reply is "imo". Everyone's "in my opinion" taken together is chaos, goes all over the place.
To lay a good basis for "ethical judgment" the expectations must be set correctly by all participants.
In this analogy toot I ramp up to one idea to help do that: https://social.coop/@smallcircles/113508151463049043
-
Billy Smithreplied to smallcircles (Humanity Now π) last edited by
I've found that the Servant Leadership pattern works best for me, but it has to be balanced with making sure that other people don't take the piss.
-
smallcircles (Humanity Now π)replied to akdb last edited by
@akdb yes, burnout is a common theme for maintainers of popular FOSS projects, unfortunately. So many more aspects than just "the fun of coding" start to play a role as a project gains traction and popularity. For many project that also happens spontaneously, and only much later there is a realization that "things are getting serious now". And then a hobby turns into full-time volunteering and dealing with people who feel various levels of entitlement to be heard or see their contributions added
-
smallcircles (Humanity Now π)replied to Nemo last edited by
Indeed. I define a #FSDL as the process where you take things explicitly into account. See e.g https://social.coop/@smallcircles/113508307986680735
-
smallcircles (Humanity Now π)replied to Dawn Ahukanna last edited by
Nice diagram. Though I am wondering if you aren't addressing a slightly different angle here.
I am sorry. This thread has exploded, and I cannot keep up with replies. There are many interesting perspectives and ideas in the many branches of this discussion, though.
-
smallcircles (Humanity Now π)replied to Billy Smith last edited by
Yes. Nice that mention. We get some good best-practice/ design pattern names here, and input for a conceptual model on how moving parts fit together.
-
Billy Smithreplied to smallcircles (Humanity Now π) last edited by
I was just using it as a practice before i knew the formal name for it.
It's a creative, constructive, anarchist approach that makes you put your energy where your mouth is...
"If i have enough energy to complain, then i have enough energy to fix it."
Also, learning new skills is fun
-
smallcircles (Humanity Now π)replied to Billy Smith last edited by
Yess. That's the attitude!
-
Esther Payne :bisexual_flag:replied to smallcircles (Humanity Now π) last edited by
@smallcircles I think it depends. On the type of project and what community grows up around you. Like if you're building an app but federated, then expectations are set.
If the criticism leveraged is about trust and safety then yes. If you've taken funding absolutely. If your project is the dominant player in blogging and you endanger the livelyhood of the folks who helped you make it popular again yes.
-
Esther Payne :bisexual_flag:replied to Esther Payne :bisexual_flag: last edited by
@smallcircles If you enjoy coding and you don't build up the additional support you need you risk burnout.
It comes down to who you choose to support you on that coding. Yes many projects with a BDFL are a hobby project. You do often need a single person to direct how it should be built.
But when you start getting the pull requests and other questions, sometimes it's best to hand over some of that triage to someone else. Plus fund that help.
-
Jens FinkhΓ€userreplied to smallcircles (Humanity Now π) last edited by
@smallcircles This thread beautifully illustrates the power of definition.
Give the power of definition to the project's initiator? It's a hobby project, they can do what they want.
Give the power of definition to the users? It's a vital piece of their digital life, so the maintainer better take it seriously!
So which is it?
-
Esther Payne :bisexual_flag:replied to Esther Payne :bisexual_flag: last edited by [email protected]
@smallcircles But on occasion the BDFL criticism is justified.
In terms of Fediverse projects, it depends. But we do have a sustainability problem and yes an exploitation problem.
No easy definition, no easy answer. It would be glib to say it is.
-
Jens FinkhΓ€userreplied to Jens FinkhΓ€user last edited by
@smallcircles
The thing about the power of definition is: both views are correct.Trying to determine which is factually "more correct" is an exercise in futility.
Instead, everyone makes a choice here.
Everyone makes the choice for a personal reason.
Figure out the reason. Work from there.
-
Esther Payne :bisexual_flag:replied to Esther Payne :bisexual_flag: last edited by
@smallcircles But when you have multiple projects and have taken EU funding, if you love the joy of coding more, then you need to be open to getting some support around you.
The community also needs to acknowledge you need that support and to help you fund that support.
https://www.onepict.com/20240409-sustain.html
https://www.onepict.com/20240813-ecosystem.html