Re: [DotGNU]Professional online tech support for GNU/Linux?

[Andrew Clausen]

On Thu, Jul 11, 2002 at 11:31:47PM -0700, James Michael DuPont wrote:
> Andrew,
> 
> After reading your comments, I think that my suggestions go more into
> the area after support : bugfixing, and feature implementation. 
> 
> You are looking into end user support issues?

Right.

> I am thinking about developer support issues.

So, you think there's a market?

> Even at my work most of the users of my software will report bugs,
> feature requests, and ask questions, all related to some program or
> dialog in the software. All of these things can be traced back to some
> module or function in the software. Maybe just to an instance of the
> software running on the clients machine.
> 
> Of course, If you get a question like "this program is stopping for
> some reason, please look into it." That would be a support request that
> needs time to debug, you might need someone to log onto the server or
> walk you through it step by step. People would pay for that type of
> support. Alot of that happens on the #IRC channels.

Indeed.  I help people on IRC like this.

> I was thinking about the types of support questions that I see on the
> dotgnu/dia/gcc developers mailling list. Like : "how can I do this?,
> implement that?, how does this function work?, what does data
> strcucture that do? Oh the program is crashing here, it is slow there,
> here is a patch for that. Anyone working on XYZ? How can I get the SVG
> output to work?". Those are the types of questions that I find on the
> mailing lists and are relevant to the development of a software. 

I'm not sure about payment here.  Like, people asking those kinds of
questions often make significant contributions themselves.  Like,
it's part of the life-cycle of free software projects.  Perhaps if
the said person wants the maintainer/whoever to spend more time...
then money might enter the equation.

> Development and Bugfixing are functional areas that can be fed by the
> support team.

Right.  In fact, developers could provide support themselves!  Good
way to make a buck on the side!  (Think: poor students, or unemployed
hackers...)

> If you support team are using the right tools, all
> support issues will provide an information gain about you software and
> help pinpoint the areas that need improvement.

I think the support team should just use the normal "more-time-than-money"
channels.

> my comments follow,

BTW: are you going to comment on my suggestions in my article?
(How I think accounts should be set up, etc.)

> Fair point, I am looking at gaining information out of the source code
> for the developers. The developers are the "users" of the projects
> source code that i am thinking about. The "users" of the executable are
> served indirectly by my suggestion. The better understanding a new
> developer can get of the program, the better the final product that he
> or she can produce will be (i hope).

Can you give me an example?  Like, I'm skeptical that this would
make much sense in practice.  The said "users" are probably in the
"more-time-than-money" category?  Or at least, they're just doing
their job.

> > > Here are my 2 ? cents : 
> That should have been 2 EURO cents, ? = Euro symbol, it did not show
> up.

hehe

> > Whoa... most issues won't affect source code at all.  If they do,
> > they are no longer support issues, but either "professional services"
> > / "consultancy", or bug fixing, which are different animals.
> > (With different budgets, time-frames, etc.)
> Ok, that is a fair definition. 
> 
> Lets say we have support which tracks features request, patches to fix
> bugs, bug reports, and just general questions.

I guess this could possibly be useful, but it sounds like a lot of
work.  I think the supporter liasing with the developers should
be sufficient.  But, once a system is up-and-running, I guess it
could be useful.  I reckon it's best to wait and see ;)  (Let it grow!)

> > > >  * how is price determined?
> > > Via an ebay bidding system, people put what they will pay, and
> > > the developers sell thier time on a market system.
> > 
> > But, you've got quality issues... also, what information do
> > developers have to decide on a fair price?
> Sure the quality is an issue. It will be complex to create a contract.
> Maybe an hourly charge or a fixed prices. 
> A fair price is what the user is willing to pay. 
> Lets say we have 100 feature requests, each are described 
> by the users to the support staff. This requirement analysis is a taskt
> that can be payed for. Maybe $5 for an feature. 

I reckon I have a better solution!  See my webpage.  (You missed it?)

> > How should a user decide which price/person
> > combination is best?
> Well, you see the track history of the developer, what people said
> about his work and the history of it. You can get/lose points on each
> interaction/usecase/resulting work.

I think this is too vulnerable to attack.  I think certification should
be done by certifiers and developers, because they have a public face,
and can't ditch their identities easily.  Basically, I think advogato
is the Right Way TM.

> > > >  * how should it interface with GNU/Linux companies, like Red Hat
> > and
> > > > friends?
> > > it is competition
> > 
> > Why?  Why shouldn't they be able to participate?
> Competition because they provide thier own support that people can pay
> for, they might be spending thier dollars somewhere else.

I think it's just another way for them to enter the market.
Like credit card vs cheque.  That said, it encourages smaller players,
which may not be appealing.

> > (note: I developed a lot of this in correspondence with Dan Burcaw,
> > who's CTO of Yellow Dog Linux)
> And he would not be losing out?

Here are some options:
* he could run a branded front-end
* trusting "yellow-dog" would set the seed of the trust graph to
Yellow Dog, and their employees would get first cut at problems for
users choosing to trust them

> > This question I was asking was more about "what should the user
> > see?",
> Fine, I was just thinking how a nice dialog system could be bolted onto
> an existing system.

Please see my comments on my webpage about this.

> > not how it would it implemented (that was another question!)
> And what it will look like will be also defined by the technologies
> used. If you build it onto sourceforge it will probably look web-like.
> If you use a C# GTK client and provide a XMLRPC interface into the
> server it might be much more user friendly.

It'd be nice to have at least a web interface... more portable.

> > IMHO, bug-tracking systems should be for developers only.
> And the users should be able to find if thier bug is there easily,
> to be able to see the status of a feature or dialog element. To be able
> to click on a bit and report a bug on it. If the user cannot, then the
> support staff should be able to. 

Sure, users should have access to this info.  But I don't think they
should be obliged to go through this.

> Remember for free software, it is also important to make the bugs and
> issues visible to the interested developers.  If not anything a good
> support staff will be producing bits of new documentation in the form
> of answers to questions and also capturing new requirements. 

I agree... I meant "target audience" rather than "restricted access".

> ok, and those are driver issues, input and usage issue, all associated
> indirectly with functions, dialogs, menus and such. All can be
> referenced back to the source code indirectly by naming the dialog
> elements. We should be able to extract all the function/module/dialog
> names from the source and present them to the users and support staff
> for linking them in. This will give a common vocabulary to everyone.

Can you describe a scenario ("user clicks here and sees X!  Developer
receives Y and is enlightened!") where this helps?  I don't really
understand your point.

Cheers,
Andrew