Subject: Welcome to the MiscKit mailing list! (LONG)

From: [email-masked] (Don Yacktman)
Date: Mon, 13 Sep 1993 12:23:51 -0600

* Warning:  This message is very long.  Save it and read
it on your next coffee break, or two, or three, ...  :-)

Hello, and welcome to the MiscKit mailing list!

If you get this message, you're on the list.  Any
bad addresses on the list should cause mail to bounce
to me, but if you send a message and get a bounce,
do be sure to forward it to me so that I can fix
the problem.  (Send it to [email-masked])

Everything is now up and running, and should work just
fine.  As a reminder, messages to be distributed to
the entire list should be sent to [email-masked] and
any administrative requests should be sent to the
[email-masked] alias or to me directly.  (I'm
[email-masked]).  Please do not send administrative
requests to the list itself, as it clutters everyone's
mailboxes, something we can all live without.

One of the first things to be established is whether or
not NeXTMail messages should be allowed.  Most of the
people on the list can accept NeXTMail directly, but
there are several who cannot.  (Me, for instance.  I
have to save the message and run it through a decoder
in order to read it, which can be a bit of a pain.)
IMHO, the best way to handle this is to use ascii mail
message for all discussion, but use NeXTMail to send
pertinent attachments.  For those who do not have a
NeXTMail decoder, send me mail and I can show you just
how easy it is to decode... :-)  So, basically, no
NeXTMail unless it's got an attachment.  Any problems
with this?

Next, it is important to understand what the kit is,
what it isn't, and how contributions, etc., will be
managed.  Of course, all of this is up for discussion,
but I'll start with my perspective, and we can go
from there...

Originally, the MiscKit was a kit which I used in my
own projects.  I got tired of always including the
same objects in every project I started, so I built
a library and now I just include the library in PB,
and I'm done with it.  The idea here was that all the
classes in the MiscKit were classes which would be
used in every app I build.  For example, the String
and ExtendedApp classes are used in every app I write.

Since I found the kit useful, I released it publically
to save other people from having to take the time to
do everything I did.  Realizing that making the kit
utterly free would make it more useful, I also freed
up the license, and have now decided to accept new
contributions from the net at large.

This opens up several issues which need to be discussed:

(1)  I've been prefixing all the objects with "DAY", my
	initials, to avoid conflicts with other classes
	which might be used.  Obviously, with everyone
	contributing, this has to change.  So a new prefix
	needs to be selected.  Tomorrow I will post a
	list of suggestions which have already been made
	by several people, so let's hold the discussion
	on this one until then...but think of a few of
	your own in the meantime.

(2)  Licensing issues need to be dealt with.  I'm no lawyer
	by any stretch of the imagination, and we need to
	put a real license on the kit, at the very least
	to make sure that no one is held liable for vicious
	bugs... I do NOT want the GNU license, since using
	it would cause several people (primarily commercial
	software developers) to shy away from the kit, which
	is not what I want.  The spirit of the license, IMHO,
	should be that of free use.  The details that need
	to be decided upon are:

	a) If used in an app, credit should be given, somewhere,
	to the authors of the kit and a pointer to the location
	of the most recent source code should be given.  This
	will help people become aware of the kit and make it
	easily obtainable.  I don't think that inclusion of the
	source code should be necessary...that's too hard for
	commercial developers, and most customers couldn't care
	less about getting the source anyway.  A pointer to its
	location ought to be sufficient, I'd think.

	b) What restrictions on redistribution on CD-ROMs, etc.,
	ought to be placed?  I'd like to allow redistribution of
	only the complete source package.  Any modified versions
	should be clearly labelled as such.

	c) Should people who modify the source be requested to
	send modifications back to us?  I'd think so, but I would
	NOT require that subclasses be sent back--though they'd
	certainly be welcome.

	Those are the main issues, but I'm sure we'll come up
	with more.  The important thing here is to delineate a
	policy we're all comfortable with--and I lean towards
	keeping things as open as possible.  Once a policy is
	decided upon, it needs to be turned into something the
	vultures, er, lawyers can understand.

	One suggestion I have received on this is to take Larry
	Wall's freeware license and modify that; we'd need to
	get his permission first, though.

(3)  What should be allowed as a contribution to the kit?  This is
	asking more, what should the focus be?  The original focus
	was "objects that would be useful in every app I write."
	I think that might be too limiting.  So, then, how should
	this be adjusted?  I'm for accepting anything people are
	willing to contribute, but this leads to a problem.  If
	there is too much in the kit, when an app is linked against
	the kit, a lot of unused code might end up linked into the
	app.  The best solution to this is to split the MiscKit
	itself up into several smaller libraries.  (For example,
	there are several objects to deal with time, so make a
	"time" library for those, etc.)  Right now, the kit's not
	big enough to warrant a split, but the interest in this
	project -- and responses I've had -- suggest that it will
	be getting pretty big quite rapidly.

(4)  What do you have that you'd like to include in the kit?  Note
	that a contribution to the kit doesn't have to be a complete
	object.  Categories that extend AppKit objects would be
	really handy.  Also, bug fixes and extensions to existing
	objects would be nice.

(5)  How are contributors to be recognized?  A file in the root level
	of the kit distribution ought to be sufficient, but what
	information would you like to see in it?  Name, e-mail, and
	perhaps what you have contributed?

(6)  How is development to be controlled?  (ie. additions, changes,
	and bug reports/fixes)  For now, I see this as my responsibility
	since I started the whole thing, but it doesn't necessarily
	need to remain that way.  I'm a programmer, and not an
	administrator...but for now I think it would be best for
	me to handle this sort of thing.  Basically, I think bug
	reports ought to be directed to the list.  (Or, the author
	of the code which has the bug, if the contrib file has that
	much info, since the author would be most likely to be able
	to _find_ the problem and fix it...)  Changes and additions
	should be filtered through me.  I won't have time to do a
	complete testing/validation as I have other work to do too,
	but I can at least make sure that conflicting changes don't
	ruin some code somewhere.  As to things like modification of
	existing code, an individual ought to make sure that someone
	else isn't already working on that particular thing.  I can
	think of several ways to control this.  One is for me to
	play "Mr. intelligent RCS" and then an individual would first
	ask me if a particular project is available or already being
	done--and then I keep track of who's doing what.  A better
	approach IMHO is to distribute this, and let the original
	author of a particular object control development of that
	particular object.  (And then I'd handle coordinating who
	should develop which object.)  Two other possibilities.  Set
	up a "work in progress" file which lists available projects
	and who's currently working on them, or, two, use this alias
	to coordinate efforts.  I think perhaps the project file would
	be useful on the "who does which object" but too clunky for
	the individual changes to the object.  And using the list would
	likely generate far too much traffic.  Any suggestions as to
	how these issues ought to be handled, and any suggestions
	about the policies which should be adhered to, would be
	welcome here.  I want this to be a comfortable development
	environment.

	As a radical suggestion to how to handle this development,
	another thing that could be done is to set up a "manager"
	program that can act as coordinator.  It would be most
	useful as an e-mail address that you send mail to.  You send
	it mail to (1) add a project that could be worked on, (2)
	send in a bug report, which then becomes a project, (3)
	ask to work on a project--at which point it will tell you
	that either you have it, or who already has it, and (4)
	you can ask it to send you an index of all projects, or
	a detailed description of any project.  This software would
	sort of be an extension of a bug tracker, but could be a
	potentially useful way to manage a community project, and
	would remove a lot of the burden from the project manager.
	(I guess that's me for now.)  So, does anything like this
	exist for free?  Or, would someone like to write such a
	beast?  I think this one has potential...and could end up
	being useful for other people's projects as well!

Well, that covers a lot of the main questions that I think ought
to be considered.  If you have any suggestions for any of these
or have other pertinent questions, post them to [email-masked]
and we'll go from there!  (I suspect that the traffic will be
pretty heavy for the first week or two and then it should settle
down into a steady trickle...so brace yourself for the barrage. :)

Later,
[email-masked]                  Nepotism is a relative thing.

PS.  For the curious, there are nearly seventy addresses on the
list already, and some of them are used as distributions points
to further disseminate the traffic within a particular organization.
Welcome everybody, and let's have some fun!