cURL cURL > Docs > Survey 2014 results

curl and libcurl survey 2014 - results

About the survey

This survey ran in the beginning of June 2014 during 10 days. It was open to the public and advertised on the curl mailing lists and via twitter and Google+. The survey was hosted by google.com which lead to some users avoiding it. Other controversies among the questions led to another user category to avoid responding. Of course all answers are only indications to what the greater curl community thinks and does.

Participants

194 responses

Contributed over time like this:

Please check the protocols you use curl/libcurl for

DICT	3	1.5%
FILE	17	9%
FTP	84	43%
FTPS	34	18%
GOPHER	3	1.5%
HTTP	176	91%
HTTPS	175	90%
IMAP	10	5%
IMAPS	8	4%
LDAP	8	4%
LDAPS	7	3.6%
POP3	6	3%
POP3S	4	2%
RTMP	5	2.5%
RTSP	3	1.5%
SCP	17	9%
SFTP	35	18%
SMTP	19	10%
SMTPS	14	7%
TELNET	7	3.6%
TFTP	8	4%

Do you use curl/libcurl on multiple platforms?

Yes, more than 5	20	11%
Yes, 4 - 5		23	12%
Yes, 2 - 3		110	58%
No, just one		36	19%

How many years have you been using libcurl?

8 years or more  39    21%
5 - 8 years      56    30%
2 - 5 years      66    35%
1 year or less   26    14%

Are you subscribed to a curl mailing list?

curl-users	40	28%
curl-library	62	43%
curl-announce	33	23%
other		9	6%

How have you contributed to the curl project?

I've filed bug report(s)				47	25%
I've sent patch(es)					56	29%
I've responded to questions on mailing list / forums	43	23%
I've helped out in other ways				38	20%
I run tests or provide infrastructure			7	4%

Are you involved in other open source projects?

Yes	146	78%
no	42	22%

What are the primary reasons you haven't contributed or don't contribute more to the project?

everything works to my satisfaction                113     58%
things get fixed fast enough anyway                44      22%
the project doesn't want my changes                5       3%
I don't have the time                              64      33%
I don't have the energy                            21      11%
I don't know the programming languages used        21      11%
I find it hard to work with the curl developers    0       0%
I can't deal with the tools (git, make, diff etc)  5       3%
I don't like or use email                          4       2%
my work/legal reasons prohibit me                  9       5%
Other                                              13      7%

How good is the project and its members to handle...

1 - Really bad to 5 - Really good.

Patches
1       0       0%
2       1       1%
3       14      12%
4       56      46%
5       50      41%

Bug reports
1       0       0%
2       2       2%
3       16      14%
4       43      37%
5       54      47%

Female contributors and other minorities
1       2       3%
2       7       9%
3       33      43%
4       15      19%
5       20      26%

Attribution and giving credits
1       0       0%
2       0       0%
3       16      15%
4       27      25%
5       63      59%

Helping newcomers to the project
1       0       0%
2       6       6%
3       32      29%
4       31      28%
5       40      37%

Which are the curl project’s best areas?

You could select up to 5 areas. The same areas and the same restriction was then on the subsequent question about what our "worst areas".

transfer speeds                                         39      20%
the support of many protocols                           96      49%
the quality of the products, curl/libcurl               101     52%
the features of the protocol implementations            67      34%
bug fix rate                                            18      9%
documentation                                           62      32%
the user and developer community                        37      19%
project leadership                                      30      15%
its build environment/setup                             3       2%
project web site and infrastructure                     3       2%
support of multiple SSL backends                        29      15%
test suite                                              8       4%
its availability and functionality on many platforms    96      50%
welcoming to new users and contributors                 10      5%
footprint of the library/executable                     19      10%
standards compliance                                    31      16%
the libcurl API                                         64      33%

Which are the curl project’s worst areas?

transfer speeds                                         15      8%
the support of many protocols                           5       3%
the quality of the products, curl/libcurl               5       3%
the features of the protocol implementations            4       2%
bug fix rate                                            8       4%
documentation                                           32      17%
the user and developer community                        2       1%
project leadership                                      0       0%
its build environment/setup                             17      9%
project web site and infrastructure                     14      7%
support of multiple SSL backends                        6       3%
test suite                                              11      6%
its availability and functionality on many platforms    1       0.5%
welcoming to new users and contributors                 8       4%
footprint of the library/executable                     5       3%
standards compliance                                    3       2%
the libcurl API                                         10      5%

If you could not use libcurl what would be your preferred alternative?

wget (or code ripped out from wget)             67      41%
libsoup                                         6       4%
native lib in Perl, Python, Java, etc           40      25%
Windows native libs (wininet or the likes)      9       6%
homegrown                                       19      12%
neon                                            6       4%
serf                                            3       2%
Other                                           13      8%

If you miss support for any protocol tell us which!

Since this was a plain text field, I've parsed and edited the responses and then counted the number of times the same one occured. Only a small portion of the participants filled in this field.

  • 3 * SPDY
  • 3 * rsync
  • 3 * websockets
  • 2 * NNTP
  • zeromq
  • DDP
  • Meteor
  • RFC 1149
  • Shoutcast / Icecast
  • Strict transport security over HTTP
  • UUCP
  • cifs
  • http2
  • IRC
  • bit torrent