3 ms·

As another BDFL, I was disappointed to see that these were a set of principles about what curl/the curl project should be, rather than principles for how to be

As another BDFL, I was disappointed to see that these were a set of principles about what curl/the curl project should be, rather than principles for how to be a BDFL. Obviously, they are related - how you conceive of the project is quite intertwined with how you intend to be-a-BDFL. But the BDFL cannot by themselves satisfy most of the goals listed in TFA. If I had to sum up my own right now, without much thought: 1. keep the project actually alive by ensuring there is clear evidence to all of continuous, significant development. 2. be respectful to all those currently involved, and to all who wish to become involved. 3. always remain open to the possibility that I'm doing something wrong, and eagerly seek out criticism that may reveal that to be the case. 4. notwithstanding #3, accept that I am the expert of experts in most senses, and have accumulated a lot of domain and application specific knowledge along the way; do not get hustled by newcomers. 5. notwithstanding #4, acknowledgement that newcomers may have ideas that hold the key to improving usability, discoverability, functionality and more. In general, strive to give their ideas serious attention. 6. Be nice. Be kind. Be respectful. Answer (most) questions asked of me personally. 7. When it is possible to financially compensate people for significant participation, do so. 8. Always acknowledge the contributions of others. 9. Promote the idea of my own humanity and that of all those involved, in order to encourage kind behavior and an understanding of what is possible (or not). 10. Always remember that it is other people who make my work possible, not me.

deleted 2y ago
[deleted]
deleted 2y ago
[deleted]
peter_l_downs 2y ago
For anyone else not familiar with Paul, he is a very effective maintainer of a variety of audio related programs. These are fantastic principles and (as a neutral observer) he lives up to them. Heavy is the head that wears the crown!
em-bee 2y ago
thank you. i was equally disappointed. your list is much more interesting. i like all your points, except points 1 and 7. because i think those are project goals, not BDFL principles. i'd maybe replace those with points 1 and 10 from the article. if i were to make a list, in addition to the points made i'd also like to add a few: 1: foster inclusivity and diversity and an environment where everyone feels safe. 2: encourage collaboration and cooperation, discourage competition. 3: have an open ear for complaints about misbehavior and aim to resolve such conflicts amicably. 4h: maintain an attitude of service.
- triblemaster 2y ago
  You say 1 and 7 are project goals but I don't agree and I'll say why: 1. If you are not keeping your project alive and it is useful, then someone else will take your project and keep it more alive. and your influence will reduce. So, assuming that you are a good BDFL, you should make effort that your project is alive so that the BDFL at top is good. 2. The ability to fund people for the project is as much a story of actual resources as it is about the culture. If you do not try funding people right from the start, you will accumulate people are also not that interested in funding people. This means your project will remain a hobbyist project. And this actually impacts 1 because then your project might not be that sustainable.
  - em-bee 2y ago
    ok, so point 1 is about making sure i don't accidentally lose control of the project. i am not sure that matters. if my life dictates that i focus on other things then this is a natural development. for me the guiding principles should dictate my behavior but not my priorities. (unless it comes to priorities within the project when they affect the community). saying that i have to stay on top of the project is claiming that i am the only one capable of leading the project. that may or may not be true. it also may or may not be important for me to keep being the leader of the project. there was at least one project that i started that i was eventually no longer using and i happily passed it on to someone else. if anything, as a behavior rule i'd add: step down when the project is no longer important to me. on point 2, i am not sure. most project founders have the problem to get even themselves funded. far from being able to fund others. and i disagree that not funding people from the start means it will remain a hobby project. just look at debian. it got huge without paying people to work on it, and infact attempts to introduce paying people caused a number of high level contributors to get upset and leave the project. so yes, funding does affect what kind of people are attracted to the project, but, funding others from the start is unrealistic. and the people i pay to work on my project are people who will leave the moment i stop paying them. they see it as a job and i see them as employees or contractors (and that is not hypothetical, i am in fact paying someone right now to help me on a foss project, and i get paid from that project too (so i am a contractor with a subcontractor)). before i got paid i was an inactive member of that community, and when i stop getting paid i will probably become inactive again because i can't afford to spend a lot of time to contribute while i have to work other contracts. so i am not sure there is a benefit to the community to have these people around. participation in a community tends to be voluntary. and communities either function well when everyone gets paid in some form, or noone. paying some people and not others is asking for trouble, unless the project is a commercial entity that needs paid workers to serve paid customers. but then again, the paid workers and the company itself are not considered part of the community, but instead they are the owners of the community. that's a different relationship.
ErikBjare 2y ago
Fantastic list. I've internalized many of these myself, but great to see them spelled out.

deleted 2y ago

[deleted]

deleted 2y ago

[deleted]

peter_l_downs 2y ago

For anyone else not familiar with Paul, he is a very effective maintainer of a variety of audio related programs. These are fantastic principles and (as a neutral observer) he lives up to them. Heavy is the head that wears the crown!

em-bee 2y ago

thank you. i was equally disappointed. your list is much more interesting. i like all your points, except points 1 and 7. because i think those are project goals, not BDFL principles. i'd maybe replace those with points 1 and 10 from the article. if i were to make a list, in addition to the points made i'd also like to add a few: 1: foster inclusivity and diversity and an environment where everyone feels safe. 2: encourage collaboration and cooperation, discourage competition. 3: have an open ear for complaints about misbehavior and aim to resolve such conflicts amicably. 4h: maintain an attitude of service.

triblemaster 2y ago
You say 1 and 7 are project goals but I don't agree and I'll say why: 1. If you are not keeping your project alive and it is useful, then someone else will take your project and keep it more alive. and your influence will reduce. So, assuming that you are a good BDFL, you should make effort that your project is alive so that the BDFL at top is good. 2. The ability to fund people for the project is as much a story of actual resources as it is about the culture. If you do not try funding people right from the start, you will accumulate people are also not that interested in funding people. This means your project will remain a hobbyist project. And this actually impacts 1 because then your project might not be that sustainable.
- em-bee 2y ago
  ok, so point 1 is about making sure i don't accidentally lose control of the project. i am not sure that matters. if my life dictates that i focus on other things then this is a natural development. for me the guiding principles should dictate my behavior but not my priorities. (unless it comes to priorities within the project when they affect the community). saying that i have to stay on top of the project is claiming that i am the only one capable of leading the project. that may or may not be true. it also may or may not be important for me to keep being the leader of the project. there was at least one project that i started that i was eventually no longer using and i happily passed it on to someone else. if anything, as a behavior rule i'd add: step down when the project is no longer important to me. on point 2, i am not sure. most project founders have the problem to get even themselves funded. far from being able to fund others. and i disagree that not funding people from the start means it will remain a hobby project. just look at debian. it got huge without paying people to work on it, and infact attempts to introduce paying people caused a number of high level contributors to get upset and leave the project. so yes, funding does affect what kind of people are attracted to the project, but, funding others from the start is unrealistic. and the people i pay to work on my project are people who will leave the moment i stop paying them. they see it as a job and i see them as employees or contractors (and that is not hypothetical, i am in fact paying someone right now to help me on a foss project, and i get paid from that project too (so i am a contractor with a subcontractor)). before i got paid i was an inactive member of that community, and when i stop getting paid i will probably become inactive again because i can't afford to spend a lot of time to contribute while i have to work other contracts. so i am not sure there is a benefit to the community to have these people around. participation in a community tends to be voluntary. and communities either function well when everyone gets paid in some form, or noone. paying some people and not others is asking for trouble, unless the project is a commercial entity that needs paid workers to serve paid customers. but then again, the paid workers and the company itself are not considered part of the community, but instead they are the owners of the community. that's a different relationship.

ErikBjare 2y ago

Fantastic list. I've internalized many of these myself, but great to see them spelled out.