
FOQ – Frequently Obnoxious Questions When Doing an Open Source Project - oddell
http://taskwarrior.org/docs/foq.html
======
tikhonj
> _Why is our infrastructure important to you?_

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.

~~~
dalke
My presumption is that the question is more one of social conformity. Consider
"why don't you wear a suit?", "why don't you stand for the Pledge of
Allegiance?", "why do you eat fish on Friday?", "why can't you answer the
phone on Saturday?"

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.

------
gravypod
This "FOQ" does not come off as anything but something written by someone on a
very high horse.

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.

~~~
notacoward
> why would you not instead implement these common requests?

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.

~~~
gravypod
On every project that I have worked on, developer support for projects
increased with the amount of users.

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'.

~~~
xioxox
I've haven't noticed any increase in developers with my main project, which is
very user heavy. It's a multiplatform GUI application, something which
attracts a lot of non programmers. If you write some sort of library, you're
going to get a lot of development help. That's not the case for a GUI app lots
of people can use.

------
finnn
>Q: Would you guys consider moving off Google groups to a real mailing list?

>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.

------
laurent123456
I don't get who this page is for. Those who ask "obnoxious questions" usually
don't read FAQs or FOQs so they'll keep asking them anyway.

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.

~~~
Semiapies
I have to admit, my reaction to the repeated "Why do you care about our
infrastructure?" is "I don't, or about your project."

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.

------
rudePolice
Sounds like whining when I read it out loud

~~~
logicallee
curious what made you read it out loud? (this isn't a pointed question, your
critique applies without the article being read out loud.)

------
murkle
You missed one: "Why don't you rewrite your whole project in Scala now now
now?"

------
notacoward
I totally understand where this is coming from. Any software project of non-
trivial size has a certain kind of inertia. The code is written a certain way,
the infrastructure works a certain way, the processes and culture are a
certain way, because they have evolved over time and often at great cost.
Changing them is not easy, and not to be undertaken lightly. That doesn't mean
e.g. that moving to GitHub is absolutely verboten, but the gain in convenience
for (some) users might be offset by a _total stoppage of development_ during
the transition. Then there's likely to be a general slowdown for a while as
new secondary issues are found and addressed, as current developers make
mistakes with the new processes, etc. If the same users who demand that change
are also demanding that their favorite features be implemented (by someone
else) right away, they're putting the developers in an impossible situation.
Nobody appreciates that. There always seem to be some users with an
overdeveloped sense of entitlement, and that can utterly ruin a project for
everyone including the other users.

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.

~~~
dalke
The scenario here is "The <Operating System> package is out of date, why have
you not refreshed it yet."

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?

~~~
notacoward
Perhaps. Automatically putting the onus on the developer would be wrong, but
so is automatically putting the onus on the packager. It's a collaborative
process. Blaming the packager represents exactly the same sense of entitlement
that the author complains about among users demanding features. Packagers are
often volunteers too, doing what they do in their spare time. Usually they're
glad to push out a package for a developer who is doing their best to
facilitate the process themselves, but blindly passing the buck doesn't fit
that description.

~~~
dalke
I believe I understand your point.

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.

~~~
notacoward
> I can totally understand the argument that I should track down these people
> and ask them to update the package.

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.

~~~
dalke
> Yes, it's possible that there could be a problem with a package you didn't
> know existed

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.

------
supernintendo
The condescension on this page is staggering.

------
ForHackernews
Cool, I'll continue not using and not contributing to this project I've never
heard of until just now.

