Another checkpoint

git-svn-id: https://shorewall.svn.sourceforge.net/svnroot/shorewall/trunk@3689 fbd18981-670d-0410-9b5c-8dc0c1a9a2bb
This commit is contained in:
paulgear 2006-03-18 05:26:09 +00:00
parent 97c7b00e2f
commit 97b5c9602e

View File

@ -39,12 +39,12 @@
<para>In early March 2006, i @@@ embarked on the jorney of surveying
Shorewall users. Initially this sprang from my own curiosity: it seemed to
me that the systems at work on which i was using Shorewall were bigger and
more complex than a lot of the ones others were using, and i wanted to
find out if there were people out there who used it like i did. As started
thinking about the question's i would ask, i realised that i could ask a
few more questions that might help us as a project to understand a bit
more about all of our users.</para>
me that some of the systems at work on which i was using Shorewall were
bigger and more complex than a lot of the ones others were using, and i
wanted to find out if there were people out there who used it like i did.
As started thinking about the questions i would ask, i realised that i
could ask a few more questions that might help us as a project to
understand a bit more about all of our users.</para>
<para>I used <ulink url="http://www.zoomerang.com">Zoomerang</ulink> to
create the survey. It has a number of tools that make it really easy to
@ -53,7 +53,8 @@
great to see a practical free software alternative that we could
self-host. A number of free content management systems such as <ulink
url="http://drupal.org">Drupal</ulink> have a survey module, but when i
last looked at them, they</para>
last looked at them, they were much more limited and harder to use than
Zoomerang.</para>
<section>
<title>Take the survey</title>
@ -76,103 +77,196 @@
</section>
<section>
<title>Results analysis</title>
<title>Detailed results analysis</title>
<para></para>
<para>An important note about this survey is that it has a very small
sample size (103 complete responses at the time of writing), so any
conclusions drawn should be considered tentative. Additionally, since the
survey was open to multiple responses, it could be that some people
answered the questions about themselves more than once, despite
instructions to the contrary in the introduction page.</para>
<section>
<title>Summary</title>
<para></para>
<para>If you notice any errors in this analysis, or have any suggestions
about how to improve it, please contact the author at <ulink
url="mailto:pgear@shorewall.net">pgear@shorewall.net</ulink>.</para>
<section>
<title>Organisations</title>
<para>Small organisations dominate the spectrum of Shorewall users.
The largest group (44%) was 1-10 users - mostly SOHO LANs, based on
the comments in that section. Ninety percent of Shorewall
installations are in organisations with less than 500 users.</para>
<para>The results for the questions about organisational size and the
number of users serviced by Shorewall closely match, which seems to
indicate that the majority of those 90% of Shorewall systems are
servicing the entire organisation in question.</para>
<para>Some anomalies seem to have crept in, e.g. some responses
indicated that their Shorewall system serviced more users than exist
in their organisation. There may be some good reasons for this that
i'm not aware of.</para>
<para>Small organisations dominate the spectrum of Shorewall users. The
largest group (44%) was 1-10 users - mostly SOHO LANs based on the
comments in that section. Ninety percent (90%) of Shorewall
installations are in organisations with less than 500 users. The results
for the questions about organisational size and the number of users
serviced by Shorewall match fairly closely, which seems to indicate that
the majority of Shorewall systems are servicing the entire organisation
in question. Some anomalies seem to have crept in, e.g. some responses
indicated that their Shorewall system serviced more users than exist in
their organisation. There may be some good reasons for this that i
haven't anticipated.</para>
<para>The vast majority (84%) of Shorewall systems are administered by
only one person. Possible reasons for this might be:</para>
only one person. One question that needs to be asked is, "Why?" Possible
reasons for this might be:</para>
<itemizedlist>
<listitem>
<para>Most of the organisations in which it is used are small, and
so most of them will only have one person skilled in the area of
packet filtering firewalls. This seems a likely scenario, but a
cross</para>
<para>Most of the organisations in which it is used are small, thus
most of them will only have one person skilled in the area of packet
filtering firewalls. This seems a likely scenario, but a cross
correlation of the results of questions 1 and 2 with question 3
indicates that the number of administrators is fairly uniform across
all sizes of organisation and user base.</para>
</listitem>
<listitem>
<para>Shorewall works so well that people don't have to touch it
much. Obviously, this is the preferred interpretation of the
Shorewall project team. :-)</para>
</listitem>
<listitem>
<para>Shorewall is too hard for new users to comprehend, so one
skilled person in an organisation tends to get the job maintaining
it.</para>
</listitem>
<listitem>
<para>Shorewall works so well that people don't have to touch it
much. (This is obviously the preferred interpretation of the
Shorewall project team. :-)</para>
it. Equally obviously, this is a non-preferred interpretation. :-)
However, being a firewall generator, Shorewall is not likely to
attract the same sort of users as a web browser or music
player.</para>
</listitem>
<listitem>
<para>Shorewall administrators are a closed bunch and don't like
sharing their job around. Given the nature of packet filtering,
this doesn't seem far-fetched.</para>
sharing their job around. Given the nature of firewalls and packet
filtering, this doesn't seem far-fetched.</para>
</listitem>
</itemizedlist>
<para>This question doesn't seem to have an easy answer. In
<para>There doesn't seem to be an easy answer to thus question. In
retrospect, since there were no responses indicating 10 or more
administrators, i could have made the granularity of this question
better. Possibly we can follow this up with a further, smaller survey
better. A question about a person's role in the organisation may also
have been helpful. Possibly we could follow up with a smaller survey,
specifically about the people and organisations who use
Shorewall.</para>
</section>
<section>
<title>Users</title>
<para>Unsurprisingly, 97% of survey respondents were male. Or to put it
another way: suprisingly, there are actually 3 female Shorewall users.
Being male seems to be an occupational hazard of life in the IT
industry, and even more so in the more "nerdy" specialisations like
Linux and security. :-)</para>
<para>The largest age group of users is 25-34 years (42% of all
respondents). There were no retirees (65 and over) or minors (under 18)
in the responses. The distribution of all remaining age groups was
fairly even.</para>
<para>The largest group of users in terms of education was those with a
Bachelor's degree, followed by those with a high school education.
Fifty-seven percent (57%) of Shorewall users have a Bachelor's degree or
better. Many users' highest qualifications are not in an IT-related
discipline (42%). This remains fairly constant across the spectrum when
correlated with the highest level of qualifications.</para>
<para>Almost two-thirds of users (62%) use Shorewall as part of their
paid employment. Of these, 12% (7 of 58) do not use Shorewall as part of
their official duties. Cross correlation with level of education
revealed no major variances in this trend depending on level of
education.</para>
<para>The majority of users (73%) began using the Internet in the 1990s.
A smaller majority (61%) have been using the Internet for more than 12
years (1994 or earlier). (The single response indicating use of the
Internet (then ARPANET) since the 1960s seems to be an error.)</para>
<para>The majority of users (70%) began using Linux after it reached a
certain stage of maturity - around or after the release of kernel 2.0
(1996). However, nearly all respondents (97%) have been using Linux for
5 years or more, with almost half (47%) having 10 or more years
experience with it. It seems fair to say that as a rule, Shorewall
attracts people with plenty of experience.</para>
<para>Around one third of users (30%) have been using Shorewall for more
than 5 years, with two-thirds (66%) having used it since the 1.x series
(2003 or earlier). It seems fair to say that Shorewall users seem to
stick with the product once they are familiar with it. On the other
hand, it seems that Shorewall is not attracting large numbers of new
users, which is a concern for the future of the project.</para>
</section>
<section>
<title>Hardware</title>
<para>Ninety-three percent (93%) of users run Shorewall on i386 family
hardware, with a further 6% running it on x86-64/EM64T platforms. One
response was received indicating use of Shorewall on MIPS (Linksys WRT
platform). No responses were received for any other hardware platform.
While this is not surprising given Intel's</para>
<para>A good spread of CPU power is shown in the survey responses. The
largest group was 400-999 MHz (30%), with only 16% of responses
indicating less than 400 MHz, with the same number greater than 2500
MHz. A number of responses in the field for additional information
suggested that the machines used were either recycled desktops, or
systems that were specifically built to do the job, and had been running
in that role for a number of years.</para>
<para>RAM configuration seemed to mostly mirror CPU power, with the
majority (52%) of systems having between 256 and 1023 MB. A bias towards
higher RAM figures (only 11% of systems have less than 128 MB; 28% have
1024 MB or more) reflects the more server-oriented workload that many
Shorewall systems run (see section @@@ below). (Note that there is an
error in the released version of the survey for this question: it was a
multiple choice question rather than single choice, and thus there were
more results than expected. However, the number of errors doesn't seem
to be significant.)</para>
<para>Shorewall systems on the whole tend toward smaller OS hard disks,
with 42% having disks 39 GB or smaller. The largest group by a small
margin was 80-159 GB at 23%, with 10-39 GB and 0-9 GB coming in a close
second and third at 22% and 20% respectively.</para>
</section>
<section>
<title>Network</title>
<para></para>
</section>
<section>
<title>Software</title>
<para></para>
</section>
</section>
<section>
<title>Conclusions</title>
<para></para>
</section>
<section>
<title>Possible implications for the Shorewall project</title>
<para></para>
<para></para>
<section>
<title></title>
<para></para>
<para></para>
</section>
</section>
<section>
<title>asdf</title>
<para>asdf</para>
<para></para>
<section>
<title>asdf</title>
<para>asdf</para>
<para>asdf</para>
<para></para>
<para></para>
<para></para>
</section>
</section>
</section>
<section>
<title>Possible implications for free software projects</title>
<title>Possible implications for other free software projects</title>
<para></para>
</section>
@ -180,9 +274,10 @@
<section>
<title>Lessons learned about surveys</title>
<para>asdf</para>
<para></para>
<para>things i did right</para>
<section>
<title>Things i did right</title>
<para></para>
@ -196,15 +291,19 @@
</listitem>
<listitem>
<para>make branches when you release alpha and beta versions, and
bring the lessons you learned in those versions into the main
trunk</para>
<para>make branches when you release alpha and beta versions,
and bring the lessons you learned in those versions into the
main trunk</para>
</listitem>
</itemizedlist>
</listitem>
</itemizedlist>
</section>
<para>things i did wrong</para>
<section>
<title>Things i did wrong</title>
<para></para>
<itemizedlist>
<listitem>
@ -214,7 +313,7 @@
</listitem>
<listitem>
<para>asdf</para>
<para></para>
</listitem>
<listitem>
@ -222,6 +321,19 @@
</listitem>
</itemizedlist>
<para>asdf</para>
<para></para>
</section>
</section>
<section>
<title></title>
<para></para>
</section>
<section>
<title></title>
<para></para>
</section>
</article>