FOQ – Frequently Obnoxious Questions When Doing an Open Source Project
taskwarrior.org
taskwarrior.org
Presumably because it affects how difficult it would be to contribute to the project? This sort of "us v them" outlook seems to be at odds with the nature of open source.
I know a few Haskell projects moved from Darcs to Git recently. While it's sad because Darcs is awesome and underused, lowering the barrier to contribute is probably a net good. Questions about infrastructure like this are by no means unreasonable.
Those are structurally similar questions, with the underlying premise "you are different." What obligation does the person who is different have to explain to those who don't understand? Very little if any, I think.
Now, your presumption does have some merit. My experience says that it's very minor. Very few people contribute to a project, and infrastructure rarely plays a role.
The FOQ even points out in the second answer, "There have been seven website patches from the community in the last three years". How many more contribution do you think they would get if they switched to Markdown over HTML? And how much work would it be to convert both the website and existing practices? Is it worthwhile?
> at odds with the nature of open source
Well, yes and no. "Open source" is applied to both a development model and a distribution model. My company sells software under a BSD license. I am the primary developer, though I've received a few patches and I paid someone to work on part of the code.
The development is all through my email. Do you call that "open source" or do you prefer a different label?
The difference is less entangled in the free software philosophy. You have the freedom to develop code for yourself and distribute it, and to ignore contributions. Compare that to your view concerning open source software, where there is at least some obligation to consider external contributions.
For a project owner to need to write a page about these common questions, why would you not instead implement these common requests?
I've often done this in some of my projects, which could be considered a microcosm of this.
I've never heard of this application, but if there is a module system, why not write a few modules for some other people? Unless your api is horrible, it shouldn't be too difficult to implement all of the "Why Didn't You Implement My Favorite Feature?" if you are familiar with the code base.
Because time is finite. Apparently you're one of the few developers that doesn't have 10x more feature requests than you have resources to work on them. Good for you. However, that's not the norm.
> why not write a few modules for some other people?
See above. It's a mistake to generalize from young and/or small projects to those that have become large and complex over time.
I would understand if there was no one using this project and it was a one-person operation, but if you are getting so many requests that it is literally impossible to comply with the top 5% of them then you should have made friends with enough people in your community who would be suited for doing these tasks.
Don't get me wrong, I am not saying do every single request and I am definitely not saying spend most of your time doing requests. But my the developers admission, "Taskwarrior [...] is easy to programmatically convert to any other data interchange format."
If it would make that many people happy, to the point where you need to have a link handy to tell them "no", then it might be worth it just to write the feature that everyone seems to want, even if it is in an optionally usable format like a 'module'.
The whole document is about answering each of those common questions individually.
Hey, can you rewrite your documentation in Swedish? It would make my life so much better?
Hey, can you implement I/O using size in English units instead of metric? It would make my life much better.
Hey, can you add a GUI for me? It would make my life much better than using the command-line.
If those where the problems in this document, I would agree. However that is not the case.
"Can you switch from Atlassian to the Github issue tracker? That would be so much better for me.
"Can you switch from a custom CI solution to Travis? That would be so much better for me."
Then two years later someone comes along and says:
"Can you rewrite the documentation in reStructuredText instead of Markdown? That would be so much better for me."
"Can you switch from git to mercurial? That would be so much better for me."
And so on.
When does the madness stop?
But in the end, I am not talking about the devops around the application. The only opinion that really matters there is the one coming from the project owner.
Your obvious attempt straw-man is nothing but opaque.
What I am attempting to discuss are features for the application that the owner refuses to implement because "get out".
Had Linus said that to the first person who emailed him about building an init daemon, I don't think many people would have paid much attention to Linux.
Your analogy with Torvalds isn't that relevant. Building an init daemon didn't conflict with the long-term goals, and the advantages are reasonably clear.
Consider the FOQ "Why is Taskwarrior written in C++ and not something hackable".
We can construct a similar question to pose to Torvalds - "Why is git written in C and not a more modern language like C++?"
We know what Torvalds thinks of C++ ("C++ is a horrible language") and of that proposal.
If he ignored or blew off the first email to suggest rewriting git in C++ then we know exactly where git would be.
This demonstrates that your argument concerning "can you implement X, Y, and Z for me, it would make my life much better" has little predictive or even explanatory power.
"But in the end, I am not talking about the devops around the application. The only opinion that really matters there is the one coming from the project owner. Your obvious attempt straw-man is nothing but opaque."
I am simply addressing the section about the feature requests.
You on the other hand are painting my argument as something it is not about.
Edit: By features I mean anything under "Why Didn't You Implement My Favorite Feature?"
My comments are solely on that section.
If you're not paying us, you need to convince us that your feature is so great, that it's worth giving up our free time to work on.
This is open source. Scratch thine own itch.
I wrote some introductory Python code 10+ years ago, for one of my classes. I put it online. I now get random college students emailing me personally to ask for help doing their homework.
I distribute some of my software for free. I've since had people demand (yes, demand) essentially hours of free support time to debug their hardware configuration for them because they don't know enough to do it themselves.
When do I get to decide what is "better" for me, rather than do things which are "better" for others?
Being lazy, I spent a weekend teaching myself HTML, and did the Web option. It was linked from the course page on the college's site.
Ten years later I was still getting random emails from people who saw it, noted the .edu domain, and assumed I was an academic expert on Hermetic cults. Thankfully, a reorganization of the college's site and course pages seems to have killed it off for good.
>Sure if there was a good reason.
I haven't checked their group specifically, but every other Google Group I've tried to join without using my gmail account simply refused to let me join. People seem to insist that it's possible, but every time I've tried it's put me in an endless "verify your email" loop.
However, I could see how this kind of document could deter people who actually want to contribute, since they might not want to deal with the condescending tone of the owners.
That's part of the nature of following a random HN link, of course, but after reading that, I'm certainly not inclined to care more about this project I've never heard of. And I say this being completely aware of annoying feature requests.
That said, I have to take serious issue with one point.
> We write software. We don't make packages. Talk to your package maintainer.
Wrong. I have lots of friends who are active package maintainers. Theirs is often a thankless job, especially now that so many people seem to think the whole idea of packages is outdated now that we have containers instead (BTW they're wrong). Developers don't have to become experts in every packaging system or its rules, but they can't shirk all responsibility for packaging either. They need to work with package maintainers, fixing (and not re-creating) problems that make packaging difficult. Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery, as I see in the first paragraph of the other Taskwarrior article posted today. Packaging is an essential part of the process.
What should the Taskwarrior developers do to fix that?
You suggest the failure is due to 'problems that make packaging difficult'. But perhaps it's the lack of an active package maintainer?
However, "What should the Taskwarrior developers do to fix that?"
Let's suppose I have a package, which I update quarterly, and I have a public announcements list, set up for people to be notified about new releases, and I answer support emails.
Someone sends me an email saying the version they get through Fink is a year out of date.
What is my responsibility as a developer? Do I contact the Fink maintainer myself? Or is it more effective for a user to ask for help?
I can totally understand the argument that I should track down these people and ask them to update the package.
But I can also understand the argument that I've set up an announcement list, and provide support, so what more do maintainers need?
Yes, the personal touch helps, and maintainers get little feedback or support. But at this point it isn't really "packaging" but "interfacing with third-party distributors".
You made the comment 'Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery,'.
Going back to my hypothetical, if all of the other package distributors are up to date (RedHat, Anaconda, Homebrew, ...) and only Fink is not, how does the failure with Fink show that I haven't learned all I can about software delivery?
Really, however, we don't know the history of why that comment is there. It could be that they tried several times to update their package until finally giving up. If that were true, then they "learned" it was best to let the package users demand updates, not the suppliers.
You shouldn't even need to track them down. If it's a packaging and distribution channel you've used before, you should already be in communication with the package maintainer. Yes, it's possible that there could be a problem with a package you didn't know existed, but such cases are very much the exception. Even then, the right thing to do would probably be to suggest a better-supported alternative and/or introduce yourself to the people maintaining that package.
> It could be that they tried several times to update their package
It could be. We're giving rather a lot of benefit of the doubt to the developers, aren't we? Why not give some to the packagers? They have their own standards they need to maintain, for the sake of their users. As often as not, packaging delays are the result of developers just throwing stuff over the wall for someone else to fix up. We need to proactively fight against that tendency.
> they "learned" it was best to let the package users demand updates, not the suppliers.
Again, it's not either/or. Both developers and packagers need to be part of that conversation. Neither gets to walk away and say it's somebody else's problem. As always in open source, collaboration is critical.
My limited experience may well be the exception, but I'll bring it up anyway. I wrote an RSS module in 2003. Someone else later added it to PyPI, the Python indexer. It has also been distributed by multiple packaging systems. I had no clue. No packager has ever said anything about it to me.
Looking now, it's distributed by Gentoo, Debian, Slackware, Ubuntu, and more. It's also used in PyMediaRSS2Gen, dilbert-rss, and loads more packages.
It took me two days to write that package, and another few days of maintenance in the 12 years. Until now I believed this hand-off mechanism, mediated by PyPI, was the way to go. Because it would take me much longer to interact with all of those distributions than to write the code in the first place!
> Why not give some [doubt] to the packagers?
Because the statement you made earlier, "They need to work with package maintainers, fixing (and not re-creating) problems that make packaging difficult. Anyone who can't do that, or isn't willing to, can't claim to have "learned all they can" about software delivery, as I see in the first paragraph of the other Taskwarrior article posted today." gave no doubt to the developers.