Someone starts a new #FOSS project as a hobby activity.

[thenexusofprivacy@infosec.exchange]

@smallcircles It depends a lot on circumstances. if the person running the project describes themselves as BDFL, then of course it's accurate to describe them that way. If not, but volunteers on the project see them are acting in a dictatorial way and are demanding something different, then it'sc legitimate but I'd want to know more about the circumsnaces before saying whether or not I agree with the characterization.

Even "hobby projects" can have BDFL's. And whether or not it's a hobby project, whoever's running it can run it however they want -- it's their project! And many people think that BDFL-style organization can work better for certain kinds of projects (as long as the BDFL's making good decisions of course). But if whoever's leading the project wants to have community involvement, and the community's complaining about decision-making, it's a problem no matter what term gets used.

[smallcircles@social.coop]

@ticktok yes I agree. Yet in practice you get to deal with negative effects I sketched. How to mitigate that?

Two thoughts just come to mind:

#CodeOfConduct should include a section on Expectation wrt the project.

#StatementOfCommitment might be a document where all the ones who have ownership of (parts of) the project state the responsibilities they take onto themself.

With those 2 documents people can clearly see where the balance is between "hobby" and "formal" governance models.

[a@paperbay.org]

@smallcircles It’s easy. If they don’t like how it’s done or managed, fork it and make the hard work. But the majority is usually complaining without having the willingness to do and maintain an open source/project. It’s a doOcracy nothing more https://communitywiki.org/wiki/DoOcracy @laxla

[jannem@fosstodon.org]

@smallcircles @abekonge
At which point the wood-craving masses are free to start chopping wood for themselves.

If you set clear expectations of a communal software project then you are remiss if you don't. You effectively promised a form of shared governance, and reneged on that promise after people already invested time and effort.

But if you did not - and especially if you make it clear it's a personal hobby - then they can fork if they want, but they have little cause for complaints.

[m0xee@social.librem.one]

@smallcircles @pixelcode
Is it such a common term these days? I'm of course familiar with it, but in abbreviated form it still confused me, I even had to look it up

[abekonge@sunbeam.city]

@smallcircles good analogy. What if you are the only one that can handle that axe and supply wood to your neighborhood. Maybe there is a wood shop where they can buy it, but the shop clear-cut old
growth forest and are expensive and abusive.

Then you start cutting pieces that are too big for your neighbors ovens? You neighbors complain - but you insist on doing it your way. Now you neighbors call you BDFL.

Another scenario - you form a cutting group that the neighbors can join , the neighbors who can’t handle the axe join the cutting group - helps carrying the wood and make tea for you. The group decides to cut pieces that fits everyone’s ovens. You actually work less now.

[smallcircles@social.coop]

@a @laxla

Indeed.

I intent to maybe write something about insights I gleaned [1] from this thread, on the #SocialCoding movement's forum.

This is a #DoOcracy too, where in heading I gave it the simplest possible definition: "Pick up any task, and steer it to completion".

Discuss Social Coding

Build better together and create solutions that people love

Discuss Social Coding (discuss.coding.social)

[1] See: https://social.coop/@smallcircles/113508224930993093

[billysmith@social.coop]

@smallcircles @laxla

This was a pattern that we found taking place at our local hackspace:

Geeks, MOPs, and sociopaths in subculture evolution | Meaningness

How muggles and sociopaths invade and undermine creative subcultures; and how to stop them.

Meaningness (meaningness.com)

It's the sense of entitlement that causes the problems.

If people are willing to share the effort, then we can all build things more effectively.

[joelving@mastodon.joelving.dk]

@smallcircles there's a dimension about money and one about power somewhere in there.
As soon as you take money, expectations change to whatever purpose you took the money for. Probably not just "me having a good time".
And power: if you "control" the social media experience of many people that can't easily change provider, that changes things, where both "control" and "easily" are sliding scales.

[smallcircles@social.coop]

@thenexusofprivacy Yes! I agree with these points.

And yet there's too much leeway or wriggle room in the definition of BDFL, and that in practice BDFL is more of a vaguely defined social-cultural stereotype to label people with. Rather than something that is well understood and can be properly dealt with.

Somewhere along the lifecycle of a #FOSS project the social dynamics change, and maintainers should cope with that.

Maybe I'll write out some thoughts. Had an idea: https://social.coop/@smallcircles/113508224930993093

[smallcircles@social.coop]

@m0xee @pixelcode

Not so much a common term but a common model that people use in practice for their #FOSS project. Without realizing it often, they get into this #BDFL "zone" and then have to deal with the consequences.

There's a lifecycle for FOSS projects, that encompasses more than coding and CI.

At Social Coding movement I defined a term for this: The Free Software Development Lifecycle (FSDL) that takes this explicitly into account.

Social Coding FSDL

Free Software Development Lifecycle for inclusive culture, healthy ecosystems and open technology.

Discuss Social Coding (discuss.coding.social)

[Guest]

@jannem

I think nobody (except my daugthers) is entitled to my work.

Not even managers at work can force me to do something I don't want to do, so much that "It cannot be done" and "I don't know how to do it" and "give me a five years and a team of five very skilled engineers, and I'll do it" are well known show-stopper at work.

When I share my high-skilled work, I set up whatever license I see fit (sometime debating with #OSI board gatekeepers, cause I like #copylefts they hate) and usually set an explicit POLITICS.txt to explicitly explain the socio-technical goals of the project.

Usually it does NOT cover governance because forks are welcome (within the rules of the license, obviously)

@smallcircles @abekonge

[akdb@mastodon.social]

@smallcircles I think it's justified because, well, the developer is benevolent for sharing their work, dictator because they are making all the decisions, and for life because presumably they want to keep the project forever. For me, maybe because this is the first time seeing "BDFL", it doesn't have any negative, insulting connotations to it. :). I'm so sorry that 'BDFL' criticism about projects are upsetting people. It can't be easy seeing your brain child fall.

[smallcircles@social.coop]

@abekonge yes, it gets interesting pretty quick, right?

> What if you are the only one that can handle that axe and supply wood to your neighborhood.

Then you can take it upon yourself to do that for them. You willingly accept responsibility for it, and thereby you make a commitment to the community to do this work.. under reasonable circumstances.

It is clear, there's common understanding, and matching expectations.

I had a thought for a best-practice:

smallcircles (Humanity Now 🕊) (@[email protected])

@[email protected] yes I agree. Yet in practice you get to deal with negative effects I sketched. How to mitigate that? Two thoughts just come to mind: #CodeOfConduct should include a section on Expectation wrt the project. #StatementOfCommitment might be a document where all the ones who have ownership of (parts of) the project state the responsibilities they take onto themself. With those 2 documents people can clearly see where the balance is between "hobby" and "formal" governance models.

social.coop (social.coop)

[smallcircles@social.coop]

@Shamar @jannem @abekonge

Oh, I was not aware of an existing practice around POLITICS.txt .. is there one, and a resource to share?

I just thought of something similar at: https://social.coop/@smallcircles/113508224930993093

[smallcircles@social.coop]

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.

[iinavpov@mastodon.online]

@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@social.coop]

@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

[dahukanna@mastodon.social]

@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@social.coop]

@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