Boeing
5301 Bolsa Ave.
Huntington Beach, CA 92647-2099
Date: Sun, 29 Feb 2004 10:38:58 -0800
03 00050 60 04022901
Mr. Rod Welch
rodwelch@pacbell.net
The Welch Company
440 Davis Court #1602
San Francisco, CA 94111 2496
..
Subject:
Future of SDS
Dear Rod,
I copied you on my reply to Jack Park, and will continue to do so to keep
you in the loop on our conversation.
..
Possibility of using an open source editor as base for new SDS
In that reply I speculated on the impact of using an open source editor as
the base for an SDS rewrite, assuming such a thing could be found.
.. Just in case jack comes back with a dozen candidates, I would like to
explore the question of how much of SDS is actually reflected in the editor
itself, and whether a requirement to feed changes back to an open source
project would in any way impact the proprietary aspects of SDS.
I don't know enough to have a solid opinion, so this is just "war gaming".
As I understand it, SDS is an execution of Medit running a specific macro.
Medit also clearly understands some aspects of SDS since we can edit
individual records, use file lists and some aspects of SDS are available in
Medit. Again, if I understand, that is achieved by compiling certain macros
into the editor, and is not built into the editor directly.
.. So, it would seem that the sorts of enhancements we would need to make to
the editor itself wouldn't be proprietary to SDS, but let's look at a
(partial) list:
..
Need to be part of the editor:
1) The Medit macro language might have to be built in to the editor
unless there is a way to implement it with some sort of add-in
mechanism that would exempt it from the opens source provisions.
..
2) The use of zones for editing and searching is actually a
carryover from older style editors, and shouldn't compromise
anything.
..
3) Keystroke assignments should be configurable in any editor and
shouldn't be a problem in any case.
..
Not part of the editor - implemented with macros
1) Line numbers and line wrapping
..
2) Vertical forms
..
3) All of the aspects of linking
..
4) Record creation, the schedule and diary themselves, the index and
pointer files.
..
Am I missing anything?
..
Note that I do not have any such candidate editor, but there is no sense
evaluating any unless we are comfortable that using one doesn't cause more
problems than it solves.
..
In general, I want to explore the possibility that we could make use of open
source without having to *become* open source and avail ourselves of the best
of both worlds.
..
I have no idea whether anything exists that might help, but using existing code
is the only path I see to leveraging effort unless we can find some other ways
to enlist talent.
..
Possibility of commercial products along the path to SDS
It also occurs to me that if we talk about a 5-year plus development cycle,
that there might be a way to develop commercial products out of some of that
work. Again I don't have candidates, but it would be nice if we could do
something about revenue without getting sidetracked from our main effort.
We haven't talked in any depth about a business model for SDS since we began
discussing a three-level architecture.
..
The need for a Comm Manager role in the use of SDS seems to me to limit its
potential as a "shrink wrap" product. I don't see how even an improved,
commercial grade, user friendly, fully documented SDS is a viable mass market
item, do you?
..
There will always be the potential of consulting as a Com Manager as has been
your history. That doesn't seem to be working at the moment, but it still seems
to be the model that has worked to date. When we talk about an organization
adopting SDS, we aren't talking about them buying a few copies (at whatever
price) and going about their business.
..
Does this imply that the preferred model is a service based one? How do we work
out a business model that provides adequate (or better, abundant) revenue while
leaving time to further the development of SDS? Consulting as a Com Manager or
even a trainer of Com Managers is a lot like a full time job, when you can get
the contracts. It doesn't leave the sort of time for development that you have
when you don't have a "real job".
..
I am faced with the same issues, of course. When I am working there is very
little time left for development, and when I am not, concern over income
sabotages the effort.
..
What business model or models would meet all of these needs?
1) generate sufficient revenue to provide a good living and above
that fund further development
..
2) leave enough time and energy to make further development happen
..
3) promote SDS broadly to increase its acceptance and use to improve
society
..
4) leave time and money to enjoy life so that it isn't all work
..
It seems to me that we need to have some ideas about what the ideal scene is if
we are going to discuss business viability as well as the evolution of SDS.
..
If we continue to develop SDS while generating no revenue, what we have is a
hobby, albeit a passionate one, which is no different from those people who
spend time on open source projects or developing personal tools for which they
receive no pay -- they choose not to get paid, and we don't -- not a lot of
difference as I see it.
..
So, what do we do in the direction of generating revenue from / with SDS? The
resources that you and I can volunteer are not likely to make progress fast
enough to keep up with evolution must less our desires. We have the added
observation that work that doesn't involve using SDS doesn't contribu7t to SDS
though it tends to keep the family and creditor happier.
..
Some possibilities are grant funding from either government or private
institutions. This essentially depends on convincing someone with access to
more money than either of us has of the value of SDS to fund ongoing
development. That person is going to need a business model as well, and we
don't really have one for him either.
..
We will carry on in any case
You and I will continue to do what we can, but my contribution isn't much,
and only you can tell how long you can go before you have to get a paying
job of some sort.
..
I am prohibited from using SDS at work or trying to sell it there. I may be
able to get approval to use is, as unlikely at that seems at present, but I
will not be able to get around the restriction against my trying to sell SDS
to Boeing, and that includes selling SDS consulting in any direct manner.
..
Even if I could persuade Boeing to use SDS on the project, that would amount
to only a few copies and possibly some support contracts (which take time),
but I don't see where you could fit in to a "hands on" contract as that
would require that you get your security clearance, which is just
administrivia, and that you move down here, which is much more than that. It
makes it hard to see how that could be considered success.
.. So, while I continue to be as dedicated as ever, the facts remain that my
available energy may not be enough to accomplish a rewrite of SDS in
anything that looks like a reasonable time frame, based on current
performance, and I don't like that answer.