It is okay to release a F/OSS project where the expected set of users is you.
-
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall yup
-
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall The vast majority of the repos I have on my git server are experiments and stuff that I wrote for myself either because I needed that tool or because I found it was fun (or both). And when it wasn't fun I just stopped working on them.
I don't even think of all that as a contribution to F/OSS in general, but it's out there in a small museum. -
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
Wow, that's 1195 characters, (with spaces) you must be with privilege.
-
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall It's okay to not have issue trackers, public mailing lists, IRC channels or any social collaboration aspects in a F/OSS project.
-
Wow, that's 1195 characters, (with spaces) you must be with privilege.
infosec.exchange has a 11,000 character limit, which is big enough that I've never hit the limit.
Smaller limits exist because of a theory that it encourages concise posts. There is zero evidence that this actually works. In practice, people write long things and split them across many posts, and write 3/11 or whatever at the end. This ends up being much worse both for usability and performance: sending a single 4,000-character post across ActivityPub requires almost the same amount of data transfer as a 280-character one. But sending ten 280-character posts takes a lot more.
I wish Mastodon would make the defaults sensible instead of requiring instances to patch it.
-
Wow, that's 1195 characters, (with spaces) you must be with privilege.
@SCALETHEORY @david_chisnall Let the man share his hard-won wisdom. Juking off to the side, leading the talk astray, is just casting shade on his thoughtful post, which had merit.
-
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall
If you have no intentions on providing support to potential users of software you've built (not including yourself), then why make it accessible to the public? Is there some benefit I'm not seeing? -
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall AMEN 🫡
-
It is okay to release a F/OSS project where the expected set of users is you.
It is okay to declare that a F/OSS project that you maintain is feature complete and stop.
It is okay to stop writing new code in a F/OSS project and just review patches from other people.
It is okay to stop reviewing patches once other people are familiar enough with the codebase to do so.
It is okay to admit that a F/OSS project that you created has so much technical debt that people would be better off reimplementing it than depending on it (especially if you write down the lessons that they should learn).
It is okay if your F/OSS project doesn't meet the requirements of some potential group of users, as long as no one applies pressure to force them to adopt it.
It is okay to tell a company that depends on your F/OSS project that it's unsupported and they can pay developers to contribute if they really need it.
It's okay to say 'I created this F/OSS project to meet my personal needs, but someone else made something that meets those needs better and so I'll use theirs instead'.
It's okay to say 'I made this F/OSS project as an experiment, and the result was that I learned that this approach is a bad idea'.
@david_chisnall Torvalds did #3 iirc.
-
@david_chisnall
If you have no intentions on providing support to potential users of software you've built (not including yourself), then why make it accessible to the public? Is there some benefit I'm not seeing?For a bunch of things I've open sourced:
I release the code because it solves a problem for me. If it solves a problem for you, then you have three choices:
- You can ignore my code entirely.
- You can fork my code and start from a better (or, at least, different) point than if you started from scratch.
- You can send me a patch to make my code work better for you (and, hopefully, me).
Two of these choices may be less effort for you than if I didn't open source it. Of those, one may make the code better for me.
None of these choices by you cost me anything.
Releasing the code costs me nothing and enables better outcomes for you, some of which can also lead to better outcomes for me.
-
@SCALETHEORY @david_chisnall Let the man share his hard-won wisdom. Juking off to the side, leading the talk astray, is just casting shade on his thoughtful post, which had merit.
Had no clue, excuse my ignorance. I do hate limits as freedoms are also stripped from us by trillionaires.
-
@david_chisnall
If you have no intentions on providing support to potential users of software you've built (not including yourself), then why make it accessible to the public? Is there some benefit I'm not seeing?@zm @david_chisnall if you have no intention of giving a shit and reading the license why would I give a shit about your opinion?
-
@david_chisnall
If you have no intentions on providing support to potential users of software you've built (not including yourself), then why make it accessible to the public? Is there some benefit I'm not seeing?@zm @david_chisnall Project gets used widely -> Get name as lead developer in the Wikipedia infobox -> get invited to lots of conferences -> Profit! -> retire (I know some of these steps sound tenuous, I didn't make the rules)
-
@zm @david_chisnall if you have no intention of giving a shit and reading the license why would I give a shit about your opinion?
I don't think that follows from @lil5 's post and seems needlessly aggressive and confrontational. I read their post as a genuine question and attempted to reply. I am not able to find a positive way of interpreting your post. If it was intended to contribute to the discussion usefully, perhaps you'd be willing to take a couple of minutes to rephrase it to better communicate that intent?
-
For a bunch of things I've open sourced:
I release the code because it solves a problem for me. If it solves a problem for you, then you have three choices:
- You can ignore my code entirely.
- You can fork my code and start from a better (or, at least, different) point than if you started from scratch.
- You can send me a patch to make my code work better for you (and, hopefully, me).
Two of these choices may be less effort for you than if I didn't open source it. Of those, one may make the code better for me.
None of these choices by you cost me anything.
Releasing the code costs me nothing and enables better outcomes for you, some of which can also lead to better outcomes for me.
@david_chisnall
That's a fair assessment. I guess my own fear would be misconstrued intentions and expectations which aren't really in your control. -
@zm @david_chisnall Project gets used widely -> Get name as lead developer in the Wikipedia infobox -> get invited to lots of conferences -> Profit! -> retire (I know some of these steps sound tenuous, I didn't make the rules)
I don't have a Wikipedia page (this is emphatically not me, and neither is the professional darts player who shares our name but also doesn't qualify for a Wikipedia entry).
I must be doing something wrong.
-
@david_chisnall @zm sorry I didn't mean you personally. I've just sat through too many presentations by the kind of people I was describing!
-
@david_chisnall
That's a fair assessment. I guess my own fear would be misconstrued intentions and expectations which aren't really in your control.I can do things that make life better for some people. I can't control how other people interpret that. And I don't want to allow myself to be paralysed by the fear of how people might perceive my actions.
-
@david_chisnall @zm sorry I didn't mean you personally. I've just sat through too many presentations by the kind of people I was describing!
-
I don't think that follows from @lil5 's post and seems needlessly aggressive and confrontational. I read their post as a genuine question and attempted to reply. I am not able to find a positive way of interpreting your post. If it was intended to contribute to the discussion usefully, perhaps you'd be willing to take a couple of minutes to rephrase it to better communicate that intent?
I interpreted that as a viewpoint of the developer. Like, if you make a project open source and make your intentions known through your license, and someone doesn't read it and expects free labor, then why should I care what their expectations are.
That could be a valid way to think about it, but I think that's what I'm trying to avoid because of the adversarial mindset.
