![](http://www.gnu-darwin.org/hexley-gd-sm.png)
|
IRC Services Manual
Frequently Asked Questions (FAQ)
Table of Contents
Frequently Asked Questions (FAQ) concerning Services
Index:
A. General questions
A.1. What is Services (a.k.a. IRC Services or Services for
IRC Networks)?
A.2. Where can I find Services?
A.3. Does Services run under Windows?
A.4. How about OS/2?
A.5. Can I send you questions without reading the
documentation?
A.6. There is no question number 6.
B. Compiling and starting Services
B.1. Red Hat says GCC 2.96 doesn't have bugs anymore. Why don't
you allow it to be used with Services?
B.2. When I run "make", I get an error message like
"missing separator", "Need an operator",
"Unexpected end of line seen", etc.
B.2.5. I get an error like "Makefile.inc not
found".
B.3. I typed "./services" at the command line, but
nothing happened!
B.4. I need support for the XYZ protocol.
B.5. Whenever I start Services, I get a message on my IRC
server saying "connection refused" or something similar,
and Services gives an error message from the server saying
"Closing Link: . . .".
B.6. My IRC server is giving me messages like "Connection
to services.example.net[127.0.0.1] activated" and then
"Access denied -- no N line". Why?
B.7. When I say "/connect services.*", it doesn't
work!
B.8. Services complains in the logfile about being unable to
load the default language, or gives messages like "Warning: bad
number of strings (747, wanted 863) for language 0 (en_us)".
C. Running Services
C.1. Services always dies after about five minutes, saying
"FATAL ERROR! Can't back up nick.db".
C.2. Services can't keep up with my network—it is
eventually disconnected with "Max SendQ exceeded". What
can I do about this?
C.3. Services starts up okay, but if I try to register a
nickname, it replies with "Sorry, registration failed" or
"Internal error - unable to process request."
C.4. Services crashed with a segmentation fault.
C.5. Services' channel mode setting doesn't work. I can't
set modes with OperServ, and every time ChanServ tries to set a
mode, my server reverses the change.
C.5.5. But my U:lines are set correctly!
C.6. My server sometimes sends messages saying "Notice --
User on services.example.net remotely JOINing new channel".
C.7. How can I make Services send replies using
PRIVMSG (/msg) instead of NOTICE?
C.8. Can I make ChanServ send channel modes all at once
instead of one at a time?
D. NickServ features
D.1. Some people get nick collided when their nickname is
changed to Guest###.
D.2. Trying to use REGISTER or SET EMAIL
resulted in an "address is unauthorized" message, but the user
hasn't registered any nicknames before.
E. ChanServ features
E.1. Services ignored the SET SUCCESSOR setting and
deleted a channel when the founder expired.
E.2. When ChanServ sets the topic for a channel, it always
appends "(nickname)" to the end. How do I make it
not do that?
E.3. The ACCESS command is confusing to some
users. Can you add a channel option to select between the
ACCESS and XOP commands?
E.4. Why can't you force users to register E-mail
addresses with channels like you can with nicknames?
F. OperServ features
F.1. Using the OperServ JUPE command results in server
messages like "Server juped.server introduced by non-hub server
services.example.net" or causes Services to be disconnected.
F.2. I can't use the ADMIN command to add
Services administrators—it tells me "Permission
denied."
F.3. How can I set up multiple Services super-users?
F.4. When I add an autokill, the users matching it don't
get killed.
F.5. Services reports (via /stats u or /msg
OperServ STATS) a different number of users online than I get
from doing /lusers.
F.6. Trying to use OperServ gives me "Access denied", but my
nick is in the ServicesRoot directive and is registered, and I've
identified for my nick.
F.7. I used the RAW command to do something, and
then Services stopped working!
F.8. On Unreal, every time I use the /gline
command, Services cancels the G:line.
F.9. Services doesn't add AKILLs/G:lines for
users matching autokill masks.
Z. Bug reporting and feature requests
Z.1. Services doesn't speak my language!
Z.2. I selected a language other than English, but sometimes
Services sends responses in English instead.
Z.3. I've found a bug that's not mentioned here or in the
documentation or KnownBugs files. What should I do?
Z.4. Your Services program doesn't do such-and-such like
DALnet Services. What's wrong?
Z.5. I've got a great new idea for Services. Do you want
it?
Z.6. Examples of feature suggestions, and why they haven't
been added:
Z.7. I submitted a bug report / feature request and it got
fixed / added, but I didn't get credit in the Changes
file!
Z.8. Can I be a Services developer too?
A. General questions
- A.1. What is Services (a.k.a. IRC Services or Services for
IRC Networks)?
Services is a package of services for IRC networks.
Read the documentation for more information.
- A.2. Where can I find Services?
The latest version can always be found at the
official Services distribution site.
- A.3. Does Services run under Windows?
Services has been reported to run when compiled under the
Cygwin
[sources.redhat.com] environment for
Windows, but has not been tested extensively and is not currently
supported by the author. If you need a stable environment, please
use a supported environment (such as Linux or FreeBSD).
- A.4. How about other operating systems?
Services was at one point reported to be usable under OS/2;
however, it has not been tested recently and is not supported.
The author has also heard reports of Services being used with
moderate success on AmigaOS.
- A.5. Can I send in questions without reading the
documentation?
Only if you like getting your messages ignored and/or publicly
flamed.
- A.6. There is no question number 6.
B. Compiling and starting Services:
- B.1. Red Hat says
GCC 2.96
doesn't have bugs anymore
[www.redhat.com]. Why don't you
allow it to be used with Services?
Because, as Red Hat themselves admit (and just about anyone
involved in Linux development can tell you), some releases of GCC
2.96 did have serious bugs in them, and I have personally
verified that at least some releases of 2.96 fail to compile
Services correctly. Since Red Hat, in one of their many stupid
decisions, chose not to change the version string in the fixed
releases, I have no way to tell whether a given release of GCC
2.96 is a "fixed" one or not. Rather than have to wade through
assembly listings for every case of a bad GCC release, I've chosen
to disallow the use of GCC 2.96 entirely. The previous version of
GCC, 2.95.3, is known to work correctly with Services, as are more
recent versions (3.2 in particular); either downgrade or upgrade
before compiling Services, or install from a binary distribution
instead of the source code.
If you absolutely must compile Services using GCC 2.96, you can
override the configure check with the
-force-gcc-2.96 option. However, the author will not
provide support for any problems which occur if you override this
check.
Incidentally, Services is believed to not have any of the
programming bugs Red Hat discusses on the page referenced above.
The one exception is pointer aliasing optimization (the
"int i; *(float *)&i = 2.0;"
example), which is a bug in the C standard, and is disabled when
compiling Services anyway.
- B.2. When I run "make", I get an error message like
"missing separator", "Need an operator",
"Unexpected end of line seen", etc.
Your make program isn't compatible with the Makefile for
Services. The Makefile was designed to work with GNU
make, version 3.79 or later, and may not work with older
versions or other systems' "make" programs. In
particular, the make programs bundled with SunOS/Solaris
and FreeBSD have been reported not to work; you will need to use
GNU make on these systems. See the
system requirements section for details.
- B.2.5. I get an error like "Makefile.inc not found".
You forgot to run the configure script first. See the
installation directions.
- B.3. I typed "./ircservices" at the command line,
but nothing happened!
Services puts itself in the background when it starts, so you get
your shell prompt right back. Meanwhile, Services will continue
setting up, then connect to the IRC server specified in
ircservices.conf (or on the command line). If it doesn't
connect, you probably have the wrong IRC protocol module loaded in
ircservices.conf.
Also make sure that you are actually running one of the supported
servers. There are many, many different variations on the basic
IRC protocol out there, and I have neither the time nor the desire
to add support for all of them. See section
2-1 for information on which servers are known to work and not
to work with Services. If your server is not listed in the
"interoperates" list as a supported server, chances are it will not
work.
As always, you can check the log file (ircservices.log by
default) for error messages.
- B.4. I need support for the XYZ protocol.
Tough luck, unless you want to write support for it yourself, or you
can supply a complete RFC-style description of the protocol to work
from.
- B.5. Whenever I start Services, I get a message on my IRC
server saying "connection refused" or something similar,
and Services gives an error message from the server saying
"Closing Link: . . .".
You need to configure your IRC server to accept Services as an IRC
server. For most IRC servers (those based on the irc2.x
distribution), that involves adding two lines like the following to
your ircd.conf file:
C:127.0.0.1:password:services.whatever.net::99
N:127.0.0.1:password:services.whatever.net::99
See the example ircd.conf file provided with most IRC
server distributions for the meaning of each field.
- B.6. My IRC server is giving me messages like "Connection
to services.example.net[127.0.0.1] activated" and then
"Access denied -- no N line". Why?
This is typically caused by including a port number in the C:line
for Services, which tells your server to try to autoconnect to it
(depending on the class (Y:line) settings). This is not what you
want, because Services will connect to the server itself, but does
not listen for servers to connect to it. The solution is to remove
the port number from the C:line.
- B.7. When I say "/connect services.*", it doesn't
work!
Of course not. RTFM, and see the previous
answer.
- B.8. Services complains in the logfile about being unable to
load the default language, or gives messages like "Warning: bad
number of strings (747, wanted 863) for language 0 (en_us)".
You forgot to run "make install" after compiling Services.
C. Running Services:
- C.1. Services always dies after about five minutes, saying
"FATAL ERROR! Can't back up nick.db".
Make sure that the user Services runs as has write access to the
data directory, and that the data directory actually exists (the
latter shouldn't be a problem if you installed from a binary
distribution or ran the configure script). This means
Services needs write and execute permission on the data directory
itself and execute permission on every parent directory of the data
directory.
- C.2. Services can't keep up with my network—it is
eventually disconnected with "Max SendQ exceeded". What
can I do about this?
If you have a really large network (tens of thousands of
simultaneous users), Services in its default configuration may not
be able to keep up with all the network traffic. Here are some
possible ways to speed Services up:
- Run it on a faster computer. (Services does not need to
run on the same system as an IRC server! If you have several
computers connected via Ethernet or another type of high-speed
network, it's perfectly fine to have an ircd on one machine and
Services on a separate machine.)
- Remove all unneeded modules from ircservices.conf.
- Comment out MSNotifyAll in modules.conf
(module memoserv/main).
- Reduce the nickname and channel expiration periods.
- Reduce the size of your autokill, S-line, and session limit
exception lists as much as possible, or remove the relevant
modules (operserv/akill, operserv/sline, and
operserv/sessions) entirely.
- Reduce the maximum number of autokicks per channel. (This will
not have a direct effect, but it may keep the problem from
getting worse.)
- Increase the UpdateTimeout setting in
ircservices.conf, to reduce the frequency of database
synchronization. However, keep in mind that this will mean
more potential data loss if/when Services falls off your
network or crashes.
- Don't run in debug mode!
Services has been successfully used on networks as large as
22,000 simultaneous users with 260,000 registered nicks.
- C.3. Services starts up okay, but if I try to register a
nickname, it replies with "Sorry, registration failed" or
"Internal error - unable to process request."
Make sure you've selected the correct IRC protocol (IRC server)
module in ircservices.conf; see question
B.3 for details.
- C.4. Services crashed with a segmentation fault.
See if you can reproduce this by doing a certain sequence of
actions. If so, please report it in detail (see
question Z.3 below). If not, you're probably out
of luck; if you like, you can report it anyway, but chances are it
won't get fixed if it can't be reproduced. If you do have such a
problem, you may find the cron utility useful for dealing
with it, by making a script to check whether Services is running
and restart it if not.
- C.5. Services' channel mode setting doesn't work. I can't
set modes with OperServ, and every time ChanServ tries to set a
mode, my server reverses the change.
If you're running the DALnet, Unreal, or Undernet IRC server, make
sure every server on your network has a U:line for Services
in ircd.conf; for example:
U:services.whatever.net:*:*
Services will report this in a WALLOPS or GLOBOPS
message the first time it discovers it cannot change modes.
- C.5.5. But my U:lines are set correctly!
If the ircd.conf file was created, edited, or copied from
a Windows computer, then it may be corrupt (Windows inserts
^M characters at the end of every line), which will cause
the ircd to not recognize the U:line. Use a text editor (like vi
or Emacs) to remove the ^M characters, or re-create the
file from scratch.
- C.6. My server sometimes sends messages saying "Notice --
User on services.example.net remotely JOINing new channel".
This is normal, and happens whenever ChanServ kicks a user from a
channel in which they were the first to enter (for example, a user
without privileges entering a channel with the RESTRICTED
setting active, or a user on the channel's autokick list). In this
case, ChanServ joins the channel for a short period of time to
prevent the user from joining again immediately after they've been
kicked. If you are using the Bahamut or Unreal IRC servers, this
will result in a message like the above; it can be safely ignored.
- C.7. How can I make Services send replies using
PRIVMSG (/msg) instead of NOTICE?
You can't. RFC 1459 (the IRC protocol definition) requires that
all automated clients send all replies using NOTICE rather
than PRIVMSG, and Services follows that requirement. If
you want to change how Services replies appear in your IRC client,
change your client's settings.
- C.8. Can I make ChanServ send channel modes all at once
instead of one at a time?
Yes; enable the MergeChannelModes directive in
ircservices.conf. (Note that this has minor security
implications; be sure to read the comments in the example
configuration file.)
D. NickServ features:
- D.1. Some people get nick collided when their nickname is
changed to Guest###.
Make sure you have Guest* (or whatever prefix you
specified in ircservices.conf) listed in a Q:line in the
ircd.conf file for all of your servers. For
example:
Q::Reserved for Services:Guest*
This prevents people from using Guest### nicks and
colliding people who get their nicks changed. Note that some IRC
servers will generate messages whenever someone gets their nick
changed to Guest### by Services and a configuration line
like the above is used; you may want to modify your IRC client's
configuration so it doesn't display the messages (or change the IRC
server itself so it doesn't generate them).
Alternatively, you can set an SQline on the same mask using the
OperServ SQLINE ADD (in the operserv/sline
module), and Services will take care of making sure all servers
have Q:lines for the nick.
- D.2. Trying to use REGISTER or SET EMAIL
resulted in an "address is unauthorized" message, but the user
hasn't registered any nicknames before.
-
Another user may have set the same E-mail address on their
nickname. Use the LISTEMAIL command to see what nicknames
have the problem address associated with them.
E. ChanServ features:
- E.1. Services ignored the SET SUCCESSOR setting and
deleted a channel when the founder expired.
Normally, this is because the successor had too many channels
registered; in this case, you will see an entry in the log file
like the following:
[date] Successor (SuccessorNick) of channel #somechannel owns
too many channels, deleting channel #somechannel
If you don't get a message like this or you can verify that the
successor wasn't running into the channel limit, please report it
using the bug-reporting procedure below (question
Z.3).
- E.2. When ChanServ sets the topic for a channel, it always
appends "(nickname)" to the end. How do I make it
not do that?
This has nothing to do with Services, and is a feature of the IRC
server itself which occurs when Services sets the topic on a
channel. The "(nickname)" is not actually included in the topic,
and the second and later users to join the channel will not see it.
There is no way to disable it for the first user, unless you modify
the IRC server itself.
- E.3. The ACCESS command is confusing to some
users. Can you add a channel option to select between the
ACCESS and XOP commands?
No. Just tell your users to not use the ACCESS command.
(You can also disable the ACCESS command for the whole network by
removing or commenting out the
LoadModule chanserv/access-levels line in
ircservices.conf, but this will prevent even users who
understand the ACCESS command from using it.)
- E.4. Why can't you force users to register E-mail
addresses with channels like you can with nicknames?
Such functionality is unneeded, because ChanServ requires users to
register their nicknames before allowing them to register channels.
As a result, as long as you require users to include E-mail
addresses with nickname, you can just look up the address for the
channel founder's nickname if a problem arises with a particular
channel.
F. OperServ features:
- F.1. Using the OperServ JUPE command results in server
messages like "Server juped.server introduced by non-hub server
services.example.net" or causes Services to be disconnected.
In all irc2.x-derived IRC servers (and possibly others), every
server on the network must have an H:line for Services in the
ircd.conf file, which looks something like:
H:*::services.example.net
- F.2. I can't use the ADMIN command to add Services
administrators—it tells me "Permission denied."
Did you define yourself as the Services super-user? You need to
insert your nickname in the
ServicesRoot
directive in the operserv/main section of
modules.conf.
- F.3. How can I set up multiple Services super-users?
You can't. However, you can allow Services administrators to
obtain Services super-user privilege by setting a password with the
OperServ SET SUPASS
command; Services admins can then use the
SU command to obtain Services
super-user privilege.
- F.4. When I add an autokill, the users matching it don't get
killed.
Services does not kill users when an autokill is added; it only
kills them when they next connect. This is designed behavior,
intended to reduce the possibility of a mistyped autokill causing
the wrong users to get killed. (Suppose you typed "AKILL ADD
*@*" and then accidentally hit Enter before finishing the host
mask . . .)
- F.5. Services reports (via /stats u or /msg
OperServ STATS) a different number of users online than I get
from doing /lusers.
Services doesn't count its own pseudo-clients (NickServ, ChanServ,
etc.) in its user count, so Services will normally report a number
somewhat lower than /lusers. This number will vary depending on
which pseudo-clients are loaded, and will also change as nickname
enforcers are introduced and removed.
If you have a very large and/or busy network, there may be an
additional offset, either positive or negative, caused by lag
(1) between users signing on/off and Services recognizing them, or
(2) between Services killing a user and the servers receiving the
kill. On a network with under 500 simultaneous clients, this
difference should typically not be more than one at any time, but
it can increase quickly as the network grows in size. (If the
difference is abnormally large, see question C.2
for ways to speed Services up.)
Finally, you may have encountered a bug in Services. If the
difference in counts increases over time without a corresponding
increase in the number of users online, then this is the most
likely explanation. Make sure you're using the most recent version
of Services, then see question Z.3 for how to
report the problem.
- F.6. Trying to use OperServ gives me "Access denied", but my
nick is in the ServicesRoot directive and is registered,
and I've identified for my nick.
You need to be opered (i.e. user mode +o from using
/oper; this is different from channel operator mode) to
access OperServ.
- F.7. I used the RAW command to do something, and
then Services stopped working!
To quote from the help for the RAW command:
This command has a very limited range of uses, and can
wreak havoc on a network or cause Services to crash if
used improperly. DO NOT USE THIS COMMAND unless you are
absolutely certain you know what you are doing!
In particular, Services does not process any messages sent
with the RAW command, so if you (for example) use
KILL to kill a user, Services will think the user is still
online, and if they connect to the network again Services may well
crash, or at least fail to recognize the new user.
To summarize: DO NOT USE the RAW command under any
circumstances.
- F.8. On Unreal, every time I use the /gline command,
Services cancels the G:line.
This is designed behavior. Use the OperServ
AKILL command instead of
the /gline command.
- F.9. Services doesn't add AKILLs/G:lines for users
matching autokill masks.
If you have
EnableExclude
defined in the operserv/akill section of
modules.conf, but your IRC server does not support
autokill exclusions, then Services will not add AKILLs or
G:lines, because doing so would prevent autokill exclusions from
working properly. See section
3-4-3 for details.
Z. Bug reporting and feature requests:
- Z.1. Services doesn't speak my language!
If you would like to supply a new language module for Services,
take a look at lang/en_us.l, which is the language module
for English, as well as the comments at the top of
lang/langcomp.c, which describe the language file format.
If/when you have completed a module for your language, E-mail it to
the author for inclusion in Services.
However, by sending the author of IRC Services a language file for
inclusion in IRC Services, you agree to waive all copyright and
other rights to that file and the text it contains, and you agree
and state that no one else (such as your employer) has any claims
of copyright or any other rights to said file and text. (You will
receive credit, of course, but the copyright remains the author's.
If you are not sure whether your employer might have rights to your
translation, consult with your employer.) Also, it would be very
helpful if you would be willing to continue updating the module as
changes are made to the base English file.
- Z.2. I selected a language other than English, but sometimes
Services sends responses in English instead.
Some language files are not complete—in other words, they
don't have a translation of every message Services uses, but only
some of them. In this case, the missing messages will be displayed
in English (or in the default language set in defs.h, if
that language file has the appropriate message). You can either
wait for the primary translator to complete the translation, or do
the translation yourself and send the author the messages
translated into your language.
- Z.3. I've found a bug that's not mentioned here or in the
documentation or KnownBugs files. What should I do?
First, check the Services home page and make
sure you have the most recent version of Services; if not, upgrade
to the most recent version before reporting your bug, because it
may have already been fixed.
If you already have the most recent version, or upgrading does not
fix the problem, contact the mailing list
and report it. Make certain you include as many details as
possible, even things which seem obvious to you--because they may
not be obvious to other people. (I have seen bug reports like "I
have a problem with expiring nicks and channels"; this is useless,
because it doesn't give any details on what the "problem" is, such
as when it happens, what the last-used times of the nicks and
channels were, or anything else that could be used to find the
alleged bug.) Include at least the following information:
- The version of Services you're using
- The operating system (name and version) and type of machine
(CPU) you're using
- What you did that caused the problem
- What Services did in response
- What you think Services should have done instead
- Whether the problem happens every time or just occasionally
If possible, try and reproduce the problem on a clean install
(i.e. empty databases), starting from registration of
nicknames and channels; this will help pinpoint where the problem
is.
You may be asked for a "debug log"; this means a log created by
starting Services with the -debug command-line option,
which writes a lot of debugging information to the log file (such
as data received from and sent to the uplink server). Note that
the logfile can grow in size quickly when debugging is active, so
make sure you have enough disk space available It may be
convenient to use the -log option as well, to write the
log to a different file than the default logfile; for example:
ircservices -debug -log=debug.log
If you do not get a response to your message to the mailing list in
a reasonable amount of time, or for some reason you cannot
subscribe to the mailing list (you must subscribe in order to send
mail to the list), then you can try contacting the
author directly.
- Z.4. Your Services program doesn't do such-and-such like
DALnet Services. What's wrong?
Nothing is wrong, except your expectations. IRC Services is a
completely different program from the Services program used on
DALnet; they are similar in concept only.
- Z.5. I've got a great new idea for Services. Do you want it?
New ideas are always welcome; however, not all ideas will
necessarily be included in Services. Some suggestions are simply
impossible or not feasible to implement; others, even if
technically possible, would complicate and/or slow down Services
too much for too little benefit. In general, new features should
have wide applicability (be useful for many people) and be as
simple as possible to use, and they should not duplicate features
provided just as well or better by another program (such as an
Eggdrop bot or the like). If you have written code to implement
your suggestion, feel free to send it along with (but not instead
of!) a description of the suggestion itself.
If your suggestion is not accepted, you are of course welcome to
implement it and distribute it yourself, either as a patch to
Services or as a completely separate program.
- Z.6. Examples of feature suggestions, and why they haven't
been added:
- An option to make ChanServ stay in some/all registered channels:
I see absolutely no necessity for this feature, since (1)
Services' channel privilege and information functions will
operate whether or not ChanServ (or any users at all) are in the
channel, and (2) if someone really wants to keep a channel
open for some reason, they can use an ordinary bot. Furthermore,
having ChanServ stay in channels will dramatically increase the
amount of traffic Services has to handle, which will in turn
reduce the rate at which Services can respond to requests. (This
has also been discussed to death on the
mailing list, so please don't ask for it
to be reconsidered.)
- Automatic handling for unusual situations: For example, an
option to allow users who have owned their nick for a long time
and want to go on vacation for longer than the nickname
expiration period. Services is an assistant, not a babysitter;
it provides tools to help you manage your IRC network, but it
will not run the network for you. Situations like the above can
already be handled using Services commands (for example,
/msg NickServ SET nickname NOEXPIRE ON); it is
not worth the added complexity, in both the programming and the
configuration of Services, to automate such rare circumstances.
- A "current time" field in NickServ and ChanServ
INFO displays: Most people have clocks of some sort
either on their computer screens or on their walls (or both), and
all IRC servers, as well as Services, have a command to return
the server's current time; it is also possible to set the time
zone Services displays dates and times in (NickServ
SET TIMEZONE).
Thus a current-time field in INFO displays would simply
take up extra space for no reason.
- Z.7. I submitted a bug report / feature request and it got
fixed / added, but I didn't get credit in the Changes
file!
You may have reported it after it was already fixed or added. In
general, the Changes file lists only the first person to
submit the bug report or feature request, except when that person
is the author or a lot of people all report the same problem or
request, in which case no individual credit is given. Mistakes do
happen, though; if you really think you should be given credit for
something, or if you find yourself being given credit for something
that wasn't yours, please inform the author.
- Z.8. Can I be a Services developer too?
The short answer is, no.
The long answer is, while I accept suggestions and patches from
others, I have tough standards on what code I actually allow into
Services itself; in fact, even when I get a patch, I never use it
as is but rewrite it so that it fits in with the rest of the
Services code properly. This is the main way I'm able to keep
Services as stable and coherent as it is: I don't let anyone else
touch the actual code base.
Every now and then I have someone tell me, "But it's open source!
You have to let other people help too!" This is, however, a
misunderstanding of what open source is about. Open source is
not about having lots of people work on a single project;
that's the "bazaar model" of software development, popularized by
Eric S. Raymond's essay
"The
Cathedral and the Bazaar"
[www.tuxedo.org] (and I don't
entirely agree with his arguments, but that's another story). Open
source is only about giving users of software the freedom to modify
that software as they see fit, by giving them a copy of the source
code for the software; the difference is that those users may not
necessarily be all working together on a single project, and may
even be in "competition" with one another, so to speak, by each
releasing their own version of a program. While it may seem that
this wastes effort, the advantage is that each of those people has
their own ideas for what the software should do; each program
evolves in its own way, letting people experiment with more
features, more ways of doing things than if they were all working
on a single program. This is, in fact, the case with Services as
well; I have personally seen around a dozen derivatives of my
Services program, each with its own particular changes, and I have
taken several ideas from those other programs as well.
So in summary, while you're welcome to contribute ideas (or
patches), and you're also welcome to take the Services source code
and start your own version of it, I have no plans to allow anyone
else direct access to the Services development code base or to
delegate out various functions or modules to other people.
Table of Contents |
Top
|