Talk:Contractor List

From email list:

(Exchange started by Pete, in response to Jeff's proposal)

They must prefer open source to proprietary software when there is no appreciable difference in featureset or quality (i.e. Firefox over IE, but not necessarily OpenOffice over MS Office)

I'm as pro-OSS as the next guy, but I'm not too comfortable with dictating philosophy. I'd be much more comfortable if this item read more like "They must be familiar with open source software, and have no bias against it." I think a contractor really ought to put his/her client's needs above any philosophical leanings anyway. If I'm a client, if there's no appreciable difference, I'd expect the contractor to draw up a few unbiased pros and cons for each, and let ME make the choice. (Pete)

This is why I put safeguards into it, so that it would read as 'if the contractor is in a position where there are two equal choices, an OSS option and a proprietary option, the contractor should be of a philosophical bent such that they would recommend the OSS choice, all other things being equal.' As that situation is unlikely to happen, the philosophical bent is going to come out in other ways. (Jeff)

Let me try to explain my position more clearly. If the situation is unlikely to happen, why have the requirement? I'd suggest there is little "practical" difference between stating it your way and stating it mine - we would generally get the same kind of people on the list. (I would expect pretty much anyone who is truly familiar with open source software would tend to trumpet its advantages.)

But with the milder version, we appear less partisan. Free Geek's reputation as an organization that exists to serve the community is important, and that reputation could be blemished if we advertise policies that emphasize a preference for one kind of software license over another.

If we're going to recommend a contractor, we appear most professional if our official criteria for doing that center on the contractor's ability to serve their clients, not their philosophical leanings.

-Pete

I also beleave that there should be no requierments as to what what OS they use, mabye they only run cable. We should have a way to provide customer fead back. Are they good at what they do, or did there service suck.

Matteo (2004.01.26)

They must

• teach classes at FreeGeek or
• allow FreeGeek volunteers to shadow them in their work or
• donate their special skills for 10 hours a week average per month to nonprofits.

Isn't that a little steep? 10 hours/week becomes a lot more than that when you factor in marketing yourself 10 hours a week a little steep? Especially when the other ones aren't quantified at all? I guess I'm a little confused by the reason for any of the stuff mentioned in (2.) The concept of bartering for a recommendation doesn't sit well with me. If FG is recommending somebody, it seems that should be a reflection of FG's opinion of their ability to do a good job for the client, and nothing more.

Sure. This shouldn't be onerous, and they get to choose one of the three. The purpose of this was to encourage contractors who give back to the community.

As for reflection on opinion of the ability to do a good job, at the moment we have no way of positively determining that, only a way of negatively determining it (recommending someone and finding out from the client later). We should certainly remove anyone from the list who we find out was unsatisfactory, but unless we can come up with a way to test satisfactoriness beforehand, we may be stuck. (Jeff)

I don't think we should get too stuck on numbers. My suggestion (from which i think this sprang) just included the first two, but i think something like 10 hours a month would be fine - either 10 hours of job shadowing for an interested FG volunteer, or 10 hours of work donated to a nonprofit.

Also, we don't have the ability to test or filter people who would want to be on this list. I think the bartering is a fine way to get contractors work in exchange, give them a meaningful way to contribute to the community, and make sure we have some sense of who they are. If one of our volunteers shadows a contractor and comes back saying "wow, i was surprised how rude that guy was to the client," or "he really didn't seem to know what he was doing," then we know much more than we did before, and we might want to reconsider recommending him. This would also make more training available to our volunteers, and give highly-skilled folks a volunteering option other than build or joining the ASSes or coders. (Laurel)

• They must recommend responsible recycling of old hardware to all clients who replace hardware during their tenure, and are encouraged to recommend FreeGeek
• They must consider using recycled hardware where appropriate.

Check, check.

• They must tithe 5-10% of profits from projects we refer to them.

Again, not sure about this. Same reasons as #2. If this amount were tied to the costs incurred by FG in creating/maintaining the list, maybe. (Pete)

Think of this as a finder's fee. Work comes in through our publicity. (Jeff)

Let us also create a list, for their use, of hardware that we could make specially available to these contractors for the use in their projects, either granted to the nonprofits at the end or sold at discount. Examples: network-ready printers, matched diskless terminals, routers/firewalls, matched keyboards, etc.

I'm confused - why would FG sell at a discount, but then require a tithe?

Overall...would this list be primarily a service to (some of) our volunteers, a service to the public (including individuals, nonprofits, businesses), a service to the free/open source software movement, or a revenue-generator?

-Pete

We would sell at a discount hardware so as to support contractors' arguments for recycled hardware, which can be a tough sell in many places, and to get more hardware into the reuse stream, as contractors are likely to be more consistent purchasers than individuals. But the real purpose of that list is to keep in priority the need to offer things to contractors that individuals don't need, especially matched equipment, as many organizations prize the look of equipment that all looks the same.

The list is intended to take over the contracting functions of Collaborative Technologies, so it would, ideally, be a service to nonprofits, and an opportunity to contractors, especially OSS-friendly contractors.

It is? I had understood this as a simple response to Matthew's request, which was motivated by a desire to help callers/visitors looking for a contractor. If there's a tie-in with another issue, can we explore that in greater detail?

-Pete

This idea--a DB of people at FG with marketable skills referenced when people come to FG looking for contractors--has actually been around for a long time. I've gotten the impression that the original theme behind the idea started in the early days of (pre-)Collab, but the specific idea of the DB has been around at least as long as I have (neigh on a year now, yikes!)

A number of times I or others have brought it up, and the general response has been, "sure, sounds like a great idea!" But it's never been followed through on because there was always something more important, or it was lost in the cracks of scheduling, or whatever. Jeff's proposal is the first concrete step towards it I've seen in a while. This is something I would _really_ like to see FG have. I haven't had a chance to post my ideas on the "Direction of FG" thread/wiki (life has taken me far from my computer in recent weeks). But this project is a subset of the vision I have. (If someone of a staff-like level of responsibility--Richard, Laurel, Martin/Dave--wanted to hear my ideas on the direction, it would prolly be better to schedule some time to meet, since I don't know when I'll have time to hammer it out on a keyboard.) -- wren

I'd be glad to hear your ideas. Laurel's about to leave for two weeks. Martin and I understand the database stuff better than Dave. But maybe they'd want to listen in too. -- Richard

I have a scheduling conflict that prevents me from coming to Council meetings for the next couple months or so, but if we were to add this item on the next agenda and actually get a consensus to go ahead and do it, rather than just the informal "it's a good idea" agreement, I would hereby be willing to spearhead the project. If Jeff or others would like to help that'd make it happen that much sooner, and if someone else wanted to take on the mantle I'd follow them, but I would like to see progress on this in the very near future. I wouldn't snub compensation, but I make this offer under the expectation that I'd be volunteering my time. So far as I see it there are two sides to the project: (1) the actual database and code therefor, and (2) the the set of policies that accompany the use of that database. There'll be some interaction between these two sides (e.g. keeping track of those who've paid their "dues"), but they're largely independent projects. I think if we can get the coding done--actually have the application in hand--then there will be the impetus to design policy for it; but that until then, the whole thing will remain nebulous.

I see three areas:

1. The database/technical implemenation stuff which I see no problem going ahead with
2. The policies about how we use that database (who qualifies, do we / how do we determine their competence, etc.)
3. The ramifications that might be termed "management" of the contractors

My belief is that we'd be inevitably sucked into a situation where we're between the contractor and the client. What if a client doesn't like the work? What if they assume they can get tech support from FG, in spite of us delineating what we don't support? Etc. The fine points of the policies and the ramifications need to be ironed out. That's why there's nothing in the short term section of the Future of Collab proposal about consultants at all. Clients will see a referral from Free Geek as an endorsement, and we need to be ready for that perception. -- Richard

The only question seems to be how much investment will FG need to put in to maintain/use the application, and whether that investment in staff-hours will be worth the community benefit and costs incurred doing so. To that, a complicated system of "dues"--as presented in the wiki--will make it more expensive to maintain: more data entry. If we could simply tie it in to the fgdb like the volunteer discount at the store is (will be/should be) then keeping track of dues would be done trivially in tandem with tracking volunteer hours. The problem with that approach, however, is that some contractors (e.g. me) may have difficulty getting in to FG and it may be easier for them to help the community in other ways (volunteer at other non-profits, etc). <thinking aloud>Perhaps we could have another table to keep track of outside volunteer time for the sake of the contractor DB?</thinking aloud> The second potential big cost is maintaining current information. To that, I say we should leave it up to the contractors themselves to log in and keep it up to date. There's an issue of "how good are they really?" but the same is true of them telling the front desk people and having them type it in; the latter would just cost FG more.

Discuss, Live well,

~wren

In addition, as we desire to be able to offer neutral advice to nonprofits in technical areas, it would be a bit of a revenue generator to fund a coordinator. OSS is just our philosophy.

Jeff

Re-posted by rfs 08:41, 21 Jan 2005 (PST)