It is okay to release a F/OSS project where the expected set of users is you.
-
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.
-
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.
I am also not keen on framing the social contract as governed exclusively by the license. The license describes obligations. You get my code, I get attribution, neither of us owes the other anything, in a legal sense.
But that doesn’t mean that we can’t build a community where members do more than the absolute minimum.
-
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'.
It is okay to release a F/OSS project where the expected set of users is you.
Which explains this: code.azkware.net/csolisr/publi… I sure use my own scripts a lot - and if somebody else can take them as inspiration, well go ahead -
@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?There's a lot of abandoned code with suitable licenses that I have chosen to use for my own needs. Either incorporating it into other projects, or patching it up enough that it would do what I needed and then using it.
You don't have to be an active maintainer for me to read and use your code.
CC: @david_chisnall@infosec.exchange
-
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 put your code out there. State that people can take it or leave it and never as much as look at it again.
-
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.
@david_chisnall @SCALETHEORY I, personally, hate this Rather stupid character limits that prevent any kind of serious posts on this platform.
-
@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 it's out there. Maybe it saves someone some time down the road maybe not.
Use it or don't seems to be a rather difficult concept for some. -
@david_chisnall @nske @zm I always delete mine when someone feels the need to make one.
Let me exist in obscurity.
What you do when I'm dead and gone I do not care about. -
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'.
Words to live by!
-
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@infosec.exchange And is it also OK to use AI to code it, because I’m fine with it and if you aren’t then just move on and use something else?
-
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@infosec. Sometimes building something requires strong will and ideals.Thank you for providing the community with inspiration.
-
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 ... --- ... ... --- ... S. O. S. We need Sustainable Open Source
-
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'.
Oh that very last one. Spent a month of weekends trying to optimize something I wrote 25 years ago.
Very elegant. Very functional. Very slow for initial usage as it built itself. Some improvement over the original, but that first time sink sucks.
So the regexes stay for now. Sorry not sorry.
-
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 I once wrote and published a code-golfed Tetris clone in 4 kB of JavaScript. People started filing feature requests for it
-
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 in other words, it's okay to not attach hubris to your project. Which is something many people starting projects have a hard time to recognize and accept.
