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 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.
-
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 After all, that is why just about every FOSS license allows you to fork and develop onwards on your own.
It’s okay to just use my project as a stepping stone towards the project *you* want, without expecting me to get involved.
Feels like a lot of folks out there don’t consider that option for whatever reason.
-
J jeppe@uddannelse.social shared this topic
