週末の趣味OSSが突然バズった！ 数千人に使われて分かった「理想と現実」のギャップ

You know Reddit has a Save feature, right?

I’m aware and I use it. And I acknowledge that my list of Saved comments and posts has become a black hole for “set it and forget it”

I'll definitely read it, thanks for the recommendation.

I am testing a new model: professional independent full-time maintainers, who bill companies as contractors, providing ongoing maintenance and access to their expertise and to the project’s decision-making process.

Seems idealistic, has it worked before?

Doesn't the maintainer of SQLite do something like this?

They do, yes

Isn’t that roughly how cURL works?

It's been working for a few years by now, it definitely works for critical projects.

https://words.filippo.io/geomys/

https://fallthrough.transistor.fm/episodes/building-an-open-source-maintenance-company

Unlike a consultancy, a large majority (never measured it, north of 90% though) of our time is spent doing open source maintenance work, not client work.

/u/FiloSottile Thanks for those links. You may want to update https://words.filippo.io/geomys/ because, curiously, nowhere in that page does it actually link to https://geomys.org/

Fixed, thanks!

https://www.pointfree.co

These guys do it pretty well in the swift community.

Well maintained open source software with a
monthly subscription for access to educational videos that go over the decision making process, implementation details, tips and tricks, lessons and more about the tools they maintain.

I think they consult as well, but the educational content is where they get funding. Their educational content is fantastic, better than most of my college classes, but it’s not feasible for every project to spend as much time teaching as they do building. It does change the incentives around a project for the better imo

It's basically how GStreamer, Webkit, LLVM, PulseAudio, and similar projects stay alive and healthy. Just google arouns for open source consultancies around particular projects.

That’s how I pay my bills.

Seems reasonable enough but to be honest that sounds just like consultancy. Many software companies develop open source products or components and make money from support and consultancy related to the product they make, and sometimes individual developers too. Which is perfectly fine, just doesn't sound like a novel approach.

Not all solutions must be novel.

Copy. Paste. Edit.

because of the extra configurations that depend on commands to modify the Windows registry.

this is sad bro

Same. No one wanted to help, in fact all people wanted was for me to help them with my tool.

I archived/deleted a couple for this reason. And a couple of the hosts like codeplex are dead. Now I just build stuff for myself and everyone else can deal.

Yes, this is something that I've experienced as well. My tip for handling it: treat it as you would treat spam. If they email you, just remove the email like you would. If they make an issue, close/remove the issue. You don't owe them anything.

I recently received this issue on a small repo of mine.

The issue they found is quite obviously a typo, and a wildly minor one at that (in code commited ~3 years ago). The difference if it had been the correct variable was a color that was 40% white vs 70% white for the frame of a button on mouse hover. For them to have even noticed something that would be so minor visually is nearly impossible, so they must have just been reading the code for fun, I would have to guess.

I have no doubt it took them longer to screenshot, create the issue, and type "wtf bro" than it would have taken them to just... fix the issue and move on.

I still haven't done anything about it, because the audacity of it is just wild to me. I should close/remove/whatever the issue, but at this point it almost feels like a novelty. A monument to the arrogance of some people.

ios_palette_off.FrameHover = light_mode ? light_mode_frame_off_hover : light_mode_frame_off_hover;

wtf bro

One of the annoying things about AI generated code (which should almost always be avoided, or at least reviewed with the necessary degree of care), is that it is often hard to distinguish from code written at 4am (which should also be avoided, but is much more understandable).

A fun one is whole teams spamming comments and +1 on a request their teammates put up.

I feel like this happening to someone could be part of a super villain's back story. Awful.

If every feature request is super, then none of them are!

assholes

outright be rude

Those types of people will not only be at that end. Those will also be commenting on bug or issue reports.

Insulting users, because they encountered a bug.
(When they themselves might not be knowledgeable enough about the used software in the first place)

(The internet has trolls. Some bigger open source projects can also have paid employees.)

Too bad you can't bad them.

just because you didn’t implement a feature that they want,

Add to that: this is your project. It follows your vision. It’s perfectly valid to say no to features based on all kinds of reasons, including “this is outside the scope of what I want this to be”.

If I ever desperately needed a feature I'd just write it myself. If that was beyond my capabilities then I certainly wouldn't bitch about it.

Missing a "not" I assume

No, they're bitchy but honest

Oops thanks for the spot

Not to mention it's opensource: the whole point of it is for you to be able to implement it yourself, if the author doesn't for whatever reason, and to fix the bugs you find, possibly even share a patch (or a pull request nowadays) so the upstream project can benefit as well.

Opensource was meant to stop blocking smart, motivated people from doing stuff they needed because some corporate types wanted to squeeze every penny out of their mediocre products in ways that are unfair to the user, not to provide an open bar for free beers for everybody and then have them complain that the beer is warm or has gone flat.

I've had this experience a couple times well. It has very much soured my desire to maintain anything open source.

Wasn't even a couple bad apples, it was like 25% of them.

And the amount of people that'll open a bug with absolutely zero information and expect you to manifest a fix into existence is insane.

I spent like two months making a pretty decent open source project for my hobby space where most options were in the $200 range with a few free but not open source tools that weren't very customizable.

What ended up happening was people making those unrealistic demands and being verbally abusive because I didn't want to implement something I viewed as out of scope, and a whole flame war between various people about how they thought the tool was useless (despite there being multiple products on the market that had the same functionality).

In the end I decided I wasn't being paid enough for that and privated the repo.

And truly, these days open source software just has to be an absolute labor of love. So many developers are dumping their time into software people feel entitled to yet won't financially support. If I cannot survive writing my software, how do people expect me to continue developing it indefinitely?

I've been considering trying again. Give it a viral license (fuck MIT) and perhaps release it without offering any support period. If people want any updates they can fork it and do it themselves.

Why did no one just provide a PR? I contributed to many project I'm not part off. Think this is a rhetorical question :S

Well the issue with my project specifically is that I was shipping a binary application, not like a library or something. So I could still get some people to use GitHub to an extent (or at least download from GitHub, with some arguments happening off-GitHub), but the majority of them know nothing of programming. Doesn't stop the entitlement, however.

Even coding savvy people go to the complaint box too. People just feeling entitled.

The ratio of the number of people who demand a feature to the number of people who send in a pull request or a diff-patch that enables the feature (tested working, not some LLM slop) is like a thousand to one.

What makes you think they would have accepted a PR for something they consider to be out of scope and not willing to maintain?

English is my 3rd language and I can not fanthom where you can deduce anywhere what I was thinking about maintainers from my comment.

because I didn't want to implement something I viewed as out of scope

From the comment you were repaying to.

Give it a viral license (fuck MIT) and perhaps release it without offering any support period. If people want any updates they can fork it and do it themselves.

That's where I've landed at this point. If the GPLv3 isn't compatible with your project, fuck you pay me. This is something I'm doing for fun or because I need it, and you're only getting it for free if giving it away also has no cost to me.

AGPL will take care of a lot of these issues :-)

While I don't want to emulate the harassers in telling you what you should do, you might be throwing the baby out with the bathwater through that approach.

Setting the project to archived has the same benefits in terms of ulcer prevention, while still allowing non-obnoxious users to benefit from your work, and potentially compensate you for it (though disappointingly few ever do). It also has the added benefit of depriving the trolls of a place to spew their nonsense, which will contribute to their frustration.

As I see it, in their twisted thinking, they get mad that your project wastes their time by existing, while failing to hold their hand and make all their wishes come true. One way I thought of to deal with that more proactively was to set up an nlp tool to detect such spam and countertroll its authors using your handle.

I breifly looked through the web for such a tool, but couldn't find anything satisfactory, nor do I have enough familiarity with the field to roll it out myself.

Just ban them. Drama queens deserve no quarter.

Sure, banning them is completely justified, and entirely appropriate. But on the internet, identities are usually free, and banning won't stop the nastier specimens from coming back for more with another account.

The main thing I like about the nlp idea is that it can keep the trolls distracted while their vitriol is ejected right into the ether, and keep the devs focused on actual problems.

I think GitHub actually doesn't let you create more than a couple accounts per an ip address (perhaps wifh a cooldown?), or at least that was the case before.

But on the internet, identities are usually free

Reputation systems can help here, though they are not without their own pitfalls.

For those kind of issues I literally just close them as “not planned” and ask them to refile with a reproduction.

I'd just backup the repo and delete it if this happens. I couldn't deal with that shit in any other healthy way than to shut it down.

I put in a ticket months ago. I told you guys the Naruto theme was clearly superior please

Yep, and the absolute dread of someone forking your repo because you know that inevitably there's an unsolicited pull request incoming that you'll have to work through, critique, and potentially reject. At best, it's a lot of work to review and merge good code. It's even more difficult to explain to someone that you've never met why their hard work is not suitable for the project or completely unwanted. From their point of view, they were trying to be helpful. From your point of view, it's just tonnes of work.

Nope, auto-reject as a general policy. Want to fork my repo go ahead. Want me to accept a PR? First step is copyright release form. Don't like it? Enjoy maintaining your own fork. Easy peasy.

Life's too short for people's bullshit.

Want to fork my repo go ahead. Want me to accept a PR? First step is copyright release form.

BRB I have to go set this up

The most interesting part of this to me is giant corporations demanding things from some random guys side project.

That's where you can make good money though, making custom modifications for companies that depend on your project.

Yeah... I would be "Gladly, I'm open to discuss my hourly rate or perhaps you would like to purchase a support agreement?"

I believe the proper response is "Bitch, pay me."

or more politely, "my hourly rate is $900"

"submit a PR"

people that thought they had the right to demand something from me

Dear Requester,

Please feel free to add feature X and then submit a pull request for review. I am also open to negotiating a contract with you to add feature X if you are unable to complete it on your own.

Thank you!

"My hourly rate is $800 per hour."

If they want you to work on your passion project outside the scope of your passion, they had better be prepared to pay for it.

The FFmpeg/Google situation seems topical, including this Atwood quote:

Thus, as Mark Atwood, an open source policy expert, pointed out on Twitter, he had to keep telling Amazon to not do things that would mess up FFmpeg because, he had to keep explaining to his bosses that “They are not a vendor, there is no NDA, we have no leverage, your VP has refused to help fund them, and they could kill three major product lines tomorrow with an email. So, stop, and listen to me … ”

It's entirely understandable how FOSS got something of a reputation for being abrasive, because I think that's just what would happen to a lot of folks if they were subjected to a deluge of people and corporations making demands of them for something that started off as something to scratch their own itch.

The default answers should probably be one of these two:

"Sure, I'll take a patch to fix that. If you don't have time to write the patch yourself, I'm happy to discuss consulting rates."

or:

"No, sorry, that's out of scope. If you really need that, I recommend forking."

I want to know more but I respect your desire to be nameless. I hate this for you, though, regardless.

+1ing the guy who wants to know more but fully understands if you think sharing more will compromise your anonymity 

I really hope your employer handled it correctly.

That’s fucking crazy

Someone once friended me on facebook to try to get me to update one of my projects to Python 3.

I emailed a dude's personal email on his GitHub when the google chat plugin for semantic versioning broke and I made a PR for fixing it so it would display the content again after google chat deprecated the old cards.

I internally debated for weeks about how appropriate that would be, and finally just did it. I felt fucking awful the entire time. He responded with a thank you and that he ignores all GitHub notifications because of spam from other project and merged it an hour later.

I still awful about it to this day, I would kill myself before going to someones employer.

Employer is definitely insane, but sometimes it's easier to reach authors by other means. There's a professor that manages a key open source project I use, it's just easier to email him. 

If they didn't want to be contacted via email, they wouldn't have it visible on their github account.

That's assuming they put it on their profile. People forget that commits contain an email address

I messaged a guy on Indeed one time because he was squatting on a domain that I wanted haha

ignores all GitHub notifications

This is how I handle things. I have exactly zero obligation to anything with my public repositories unless I feel motivated to do so. There's something about 'as is' which people really don't understand.

Pen names are valid for literature, so that's exactly what I do when authoring code. It's real, but just an alternate real version of me, completely separate from my work identity.

Guy Codeman

Kojima-san is that you?

Cat Branchmain

Saul Hacksman

I think this is probably also common on social media because it doesn't make sense to attach your career info to every forum/blog/social network you respond to unless it's part of your job or industry.

Sometimes a hobby is just a hobby.

Damn, who contacts someone else's employer for personal projects?

I do have one caveat though with the advice of being anonymous: being anonymous doesn't mean there shouldn't be a good and clear way to communicate.

I'm in a weird position there, because I'm mainly a security researcher, and on my own time I look for security issues in open-source software. That's how I contrubute to projects I like. The "industry standard" way to deal with vulnerability reporting is to share them privately at first (limiting the number of people that know about it reduces the risk that it's exploited) and then after a few months publicly release the vulnerabilities (because secrecy only works to a point, if you found them somebody else may have as well, and you're trying to strike a balance between letting the developpers fix their project comfortably and protecting the users who have a right to know that their security is at risk if the developpers don't take the issue seriously).

This puts quite the burden on small developers because they're often doing that for fun, and now they receive outside pressure to change sometimes large parts of their software within a specific time frame. I'm sincerely sorry that this is the case. There's just no good other way when balancing comfort of the developers against the security of the users.

But that's when you even find how to contact the maintainers. As explained you don't want to just open a public PR for these issues, but I've quite often had trouble finding a mail or any way really to contact developers on projects. You don't want to send your report to just any contributor either. It really makes the whole process quite difficult.

So please, unless your project is truly dead, especially if it has users, leave some means of communication so I don't have to go full osint to find someone to talk to.

[I'm not the guys you're responding to, just to be clear]

That's a great perspective, thanks for sharing.

I think my reaction to this will greatly depend on what's my intent in sharing my code. If it's just so I can point to it on my resume, or because "why not?", I'd say security fixes have the same weight as any feature request. If I'm feeling up to it, I'll do it, but I don't make any promises. If my license says it's ok, please fork it and fix it for yourself (and share it if you feel like it). If you didn't take that into account before building on top of my project, that's not my problem.

Of course, that's a completely different situation if I'm actively pushing people to use my code, then I would feel some sense of responsibility. I haven't found myself in that situation, so I can't speak for it.

On that note, I have absolutely no issue with hobby projects that don't claim anything as long as the expectation is made clear to potential users. But you'll have no trouble finding tons of "secure messengers" for example on github of people that are just learning python (or worse, just discovered chatgpt) and have a readme that says "Military grade AES encryption secure messaging" or whatnot. People that find these projects may take that at face value and so there is value in either fixing its issues or clarifying the expectations users should have for the project.

My most common recommendation is simply to add a line to the readme indicating that the project is not safe and should not be expected to be safe as it is a toy project (not necessarily in these words of course) but most projects simply don't care enough to advertise that fact to their potential users. In my experience they often don't even consider to have users, but if you're on github then you're published and you may very well have people that use your project.

Security vulnerabilities aren't like other bugs. If you have a regular bug, something doesn't work the way it should, it's not the end of the world. As long as it's not bricking your system who cares really, if that bothers you fork or switch or wait for someone to care enough to fix it. But security doesn't work backward: if you run something with a vulnerability and it's exploited you can't retroactively decide to be secure, it needs to be proactive. And it's generally not about the application itself but often about banking, crypto wallet, ssh keys… Even if your application is an only pizza recipe book that, by itself, doesn't manage anything too serious, the impact of a security vulnerability generally go beyond that. That's why I think they deserve special care, at least to be clear with the user what your position on these issues is so they can make an informed decision.

I respectfully disagree. I believe your point rests on the idea that once a tool is "published", the burden of clarifying its level of security rests on the author. That is false, the burden is 100% on the user. If you install something from the internet, you should always assume it is compromised, unless you made sure it isn't.

That's even more the case when we're talking about libraries - things that are primarily consumed by experts on their field. If someone in my company runs `npm add foo` without making sure `foo` is safe, and then something bad happens, their asses are on their line. Period.

To be clear I do agree that there are instances when that responsibility is transferred to the author -- for instance, if you sell something, you should make it very clear how much security and updates the buyer should expect. But we shouldn't generalize that.

Lastly, totally agree that security issues are different than feature requests -- I'm just not interested in providing any code that guarantees security fixes without getting paid very well for it. If that's a problem for potential users, they can either pay me or use something else.

I'm going to disagree. Respectfully so, but still. And I'm tempted to leave it at that, "agree to disagree", etc. But I think this is important enough that it should be discussed, calmly and with nuance. I may not convince you, but I'd like to try anyway, and hopefully provide a simple, free and agreeable solution to the conundrum.

First of all, where do I agree with you? Because I do, to a point. I realize that publishing FOSS is already quite the gift and that this added responsability is quite the burden on independent programmers. I also think that there are many situations that are quite unacceptable: the way big corporations like Microsoft and Google throw their weight around expecting small developpers to quickly fix things in their libraries (curl comes to mind) because their stack depends on it when they clearly have the money to contribute either a solution or at least support for the development frustrates me a lot. I realize that their security and development teams are probably so far away that they might as well be different companies, but still, I think they could and should do better. And I also think that users should be more careful online generally. So if I know that, why do I still think that in most cases the burden must land on the developer's shoulders?

I think the core concept is expectation.

Why does it feel ok to make the developer responsible when they sell something but not when they give it? Is it because in that last case they have money do do the corresponding development? That's probably part of it, but tons of small developpers make almost no money, it's not like they have that much more leeway than hobbyists. I think it has more to do with expectations. When someone sells you something, they're essentially saying "this is worth buying". As a customer you have a reasonnable expectation that it will not be entirely shitty. So when it turns out to be, you feel scammed, even though you're the one that decided to buy that thing.

Rephrasing things in that context, I believe what you're saying is "the expectation shouldn't be that the thing is ok, it should be that the thing is bad, and so it is your responsability to check it". So let's evaluate that.

First of all, there are plenty of things I'm a user of and don't pay for. If vlc has a vulnerability tomorrow and doesn't fix it and my computer gets hacked, I'll blame their developers for it and I won't feel like a hypocrite doing so. Why? There are a few things.

• VLC is what I'll call an "end program". It's not a library, it's destined to be used by end users, not builders.
• End users cannot be expected to meaningfully check the security of what they download.
• There also a big part of "your bug, your problem". Where I'm from, if you write a bug it's your responsability, you don't blame someone else for introducing it.

I realize that the "your bug, your problem" is quite cultural so I won't dwell on it, we might well have different views on it.

The end user thing though is different. Sure you can tell people to be careful etc, but the truth is that you can never expect an end user to meaningfully check the security of VLC. They might do the already excellent job of asking their most trusted IT-capable friend (probably chatGPT) whether https://www.vlclan.org/ is actually the official website and if it's ok to download it from there, but that's hardly a meaningful check. Yet if a new security issue is found in VLC, all its users are impacted without even knowing it. We could ask VLC to fix it once and help millions of people, or we could blame each user for individually not checking what they downloaded.

It might seem like I choose a biased example. Of course with millions of users things are different. Of course a program used by tons of users is different. But IMHO it really isn't.

You talked about the hypothetical case of one of your coworkers (let's call him Bob) running npm add foo without checking that foo is safe. Now the situation seems different:

• It's no longer an end user, it's a builder. They can write programs.
• It's no longer an end program, it's a library. It's not expected to be used directly by non-technical users.

So okay, you expect Bob to check foo before installing it. Now how is Bob supposed to do that?

• He first considers the appearance of the package: Is it of good reputation? Is it actively maintained? Do they have tons of bugs waiting to be solved? Does it make any guarantees?
• He then has to read the code. Not just a bit, the whole thing. It's his ass on the line if there's a nasty bug in there after all, he has to read it all.
• And I mean all, not just that package but every transitive dependency. After all nobody else will be blamed if foo depends on a broken JWT package. So he does the same thing again, check the reputation, check the code.
• And he has to actually find these vulnerabilities. And there… Look, I've never met Bob, I'm sure he's great, but I don't trust him to find every vulnerability anymore than I trust my aunt to check the security of VLC. I've spent more than a decade auditing source code for vulnerabilities, but I've never met a developper that I would trust to fully check the security of a library and its dependency (aside from the most simple cases of course). Heck I wouldn't even trust myself to do it and it's literally my job so I'm not blaming Bob here. How many Bobs know enough about cryptography to understand when it's badly done or know enough languages to properly review foreign dependencies? It's tough work.

But ok, Bob's a hero, he does the work and he does it well. And then, a month later, your website is hacked. A few weeks later you hear that there was an update in a dependency of foo that completely shattered the authentication stack and anyone could get bypass your login page, that they knew about it but hadn't fixed it yet. Should Bob be blamed for the incident? Should the developper of the foo package be blamed for including that library? Or should that library's maintainer be blamed for knowing about the bug and not fixing it? Maybe nobody should be blamed. I could get behind that. But if we do assign responsability I don't think Bob would be my first choice.

What's my point here? My point is that pushing that responsability fully onto the users simply doesn't work. It cannot work. It does nothing to bring security forward (because nothing changes if we blame the user), it simply cannot be done by end users, and it (not so simply) cannot be done by builders. Even when you do the verification work, bugs can be introduced later, and that's disregarding the fact that it's so damn hard to actually properly check a package.

I don't think we can expect that of users. I do think however that there is a middle ground that is somewhat easy to reach.

Simply set expectations straight. If you don't think you can sustain that responsability, simply tell that to the user. Just write on your website "This is a hobby project and users should not expect it to be secure", or on the readme for your library "While I welcome bug reports regarding security issues, this is a one-man project and I cannot guarantee that I provide no security guarantee". That way when Bob checks the library out, they don't have to scan the entire codebase to know whether it looks like you're serious about your security, they know what to expect. If my aunt sees that on VLC's download page, she might get spooked, she might underestimate the risk, she might accept the risk, either way she has much more information to make a better informed decision than before. And if Bob still doesn't do the simple check of reading the readme and introduces a big issue because of it, then sure, fire away.

I don't think it's too much to ask for developers to tell their users what they can expect from the software. If you don't want to guarantee that you'll fix things that's fine by me. I'd prefer it other way, but we are humans and have only so much time and money which I totally understand. However, just be clear about it to your users. Don't just blame them for failing to spot your bugs before falling victim of your mistake. That will also be helpful to security researchers like me because what do you expect us to do when your program turns up to have a big vulnerability? We're probably not users but we feel a responsability toward them when we know of a big hole, so who are we to contact but you, the developer? We have no interest in forking and it wouldn't solve anything, and my oh my am I not a developer. You really don't want a PR from me, just because I can read code well doesn't mean I write it so. If you're clear about the fact that you don't intend to care about it, it's helpful. I might report it, just in case, but I won't push the issue and I'll skip directly to the public announcement part so hopefully the users at least know of the problem and can steer away from your project if it puts them in danger, and I won't spend weeks anxous of seeing it resolved, of hearing back from it. It's not much, and I won't speak for every security researcher, but at least I really care when I find something in a project. I'll really go out of my way to help out, checking in regularly to see if things are ok on your end, and all that on my free time as well because where some people develop as a hobby I try to help FOSS projects as a hobby as well. It's ok if you don't want to spend your free time fixing security issues in your pet project, but I'd be nice if you'd also help me not lose my time finding issues in your project only to learn that you don't intend to do anything about it. Just be upfront about it.

So, yeah, I believe that being clear about expectations is really in everyone's best interest. Less time wasted for the devs, better information and security for the user, better use of researchers' time, at the simple cost of a single line saying "Don't expect this project to be secure".

How much were they willing to pay?

1 - Exactly, I even put that in the article.

2 - Thank you very much, my friend.

3 - That’s a great idea.

I think that the app nzb360 might be a good example, they would have a list of planned features and when it hit a funding goal then it would be worked on and added.

thats a great exemple

for 3, to keep goodwill, ideally the paid features would not be privacy/security related

Do what you want with it. That is all.

Yes, they believe the tool belongs to her.

Hahaha, that’s a great idea! It’s perfect for protecting myself from unfriendly users.

I am not a lawyer or English native, but I think that most of FOSS licenses already have a disclaimer of warranty and limitation of liability. The disclaimer of warranty even is quite the only part remaining in the BSD 0-clause license.

excellent words, I will certainly consider them

That makes perfect sense, my friend. Thanks for the tips.

Thanks for the guidance — I ended up implementing exactly what you suggested.
The project now has structured issue requirements, a detailed PR template, contribution guidelines, and labels to keep things organized.
Already seeing smoother contributions because of it. Really appreciate your insight. https://github.com/kaic/win-post-install/blob/main/CONTRIBUTING.md

OP's seems to have a lot of optional tweaks, like disabling timeline, etc.

Ninite is installation only, no tweaking.

This seems to use winget, so no extra downloads, and has a bunch of commands to change settings as well.

Cool idea.

I can't help but feel that adding some text to say there's no guarantee of support - just intention.

Given how entitled some people act (as seen in this thread), I would not be surprised if someone tried to sue, saying "you said you would support it, but you're not doing what I want".

👀

I recently created a contribution guide, a template, a donation method for the project, and strict issue control (largely based on your comments). Thank you very much for the tips, my friend. https://github.com/kaic/win-post-install

hahahahahaha great comment bro

This is the way. A balance that is healthy for everyone. I follow a similar approach when picking licences. I share so everyone can benefit, but I pick one of the GPL derivatives because big corporations avoid it like the plague. People benefit from my projects, and companies have to waste resources to re-implement it if they need it.

Right? OP asking more questions than telling the story. It's like an engagement bait. It doesn't even fit in this sub.

Yea lol

And he said it "blew up" with stars and issues, it was at 99 stars (now 170) when I first checked, and 8 total issues (now 9)!

That was apparently enough to write an op-ed...

The engagement feels extremely fake, I want to say extreme bot usage. I'll report it.

starts and issues <> visits and usages

Well you didn't share your website traffic data. I went by what you said:

Stars spiked, issues poured in, people asked for features I never planned, and I had to make fast decisions about scope, documentation, and user expectations.

Don't get me wrong, but ~10 issues is not a spike, ~180 stars is not something crazy.

The entire thing feels extremely botted and self-promotional, the blog posts look like they've been prepared beforehand, and are overly dramatic. Even some comments on reddit are fishy.

So it's time to make money.

nice point