Ask HN: 1 minute Survey About Open Source Software in Your Products

Consider making all questions optional and you'll get more people answering.

If you really want people to do this, why do you make them copy and paste the URL into their browser? Why don't you provide a clickable link?

Here, I'll do it for you: http://www.surveymonkey.com/s/PT56NHC

... and now that I've gone to take the survey, I can't finish it because there is no suitable answer for question 6. Another of the questions I had trouble understanding the distinction between "None" and "0" as answers.

So I gave up.

Good surveys are really quite hard to design, and bad surveys are pretty near useless. It's pretty clear you're asking how much people will pay for something you're thinking of producing, so I suggest you think a lot harder about how you're going to get that information. I'll be very surprised if this survey gives you anything reliable.

Only 6 questions, I've seen much worse surveys ;-)

I marked "I only use free tools", but what I really wanted was an option like "This isn't worth paying for".

We do pay for tools we find useful.

It's good etiquette to post the results page with the poll so that it benefits the entire community, not just yourself.

I agree that Question #6, the keystone, is poorly designed.

It should also include the option "I don't know, depends on how useful it is".

I just chose a random answer since that option wasn't there (and the question was required).

Same objection to question 6 that other people have mentioned: I wouldn't pay for a service that tells me about open source software updates (because I keep up with them myself already as part of my usual process of staying informed), but that doesn't mean I don't pay for services in general.

i clicked on the "only free tools", but this is an interesting idea. how are you planning to implement it? a tool that scans our git, hg, svn and cvs repos and tells us what we have would be quite interesting (although there's the obvious hurdle of trusting third party code enough to ever run it).

i work for a small consultancy that builds bespoke solutions using open source code - we have loads of projects, some ancient (cvs!), and i am sure no-one has a clue what versions of what we used when (sure, it's documented for the client, but we don't have our own central list). now perhaps we should be better organised, but i suspect many other companies are in a similar position.

but if we were going to pay for this, how would it help us make money? is the idea that we can approach ex-clients and scare them with lists of security holes? or are they the target clients - perhaps they should be running this code to audit their systems? and that sounds so useful i am surprised that nothing like this already exists...?

A metacomment related to question 6: Ubuntu tells us exactly how many packages need to be updated, and the update is as simple as executing a single command. The problem is ensuring that functionality is not broken by things like API or subtle behavior changes. This means that updates end up happening infrequently since they need to be regression tested on a development server before being pushed to production.

If a product could solve that problem (classifying updates and performing code analysis to determine if something could break) it would definitely be worth paying for.

Note also that you're asking the wrong people, and it's going to be hard to ask the right people with an Internet post. The best candidates for this tool are busy founders/CTOs/sysadmins/engineers who don't have time to manage their updates, much less take surveys on Hacker News.

I bailed at question #5: "How many open source packages that you build your product on are currently out of date?"

It's just too vague and it implies that I'm lazy/behind. Let's say I'm using jQuery 1.x, for example, because when I was building/testing last, that was the most stable version. Today jQuery has probably 20 more "updates" since I rolled mine into production - the version number has incremented 20 times - but it doesn't mean I'm "out of date", does it? I don't believe that I have to update my use everytime jQuery goes from 1.34 to 1.35 to 1.36 all the way to 1.99.

So "out of date" is a bit problematic for me in that I don't feel the need to test/use every incremental update.