Re: removing debian-consultants list
I haven't seen a lot of business over the last year, but enough to keep
my company in business, and things are picking up enough now to get me
thinking about improving the way we go about it. I can see several very
worthwhile purposes for this list, but it's obviously not fulfilling any
of them at the moment, which is why I'm subscribed but keep thinking
about giving up on it.
Anyway, here are several topics that've been on my mind lately, and that
I'd like to see discussed in the hope that discussion will eventually
result in concrete action:
1: Re: unstable packages on stable systems
I can't reasonably recommend to my clients that they run the unstable
distribution, but there are a handfull of packages, such as HTML::Mason
and PostgreSQL, for which I really need newer versions than are
released in stable. For perl modules, I've taken to setting up the
CPAN shell to install in /usr/local or another location, for PostgreSQL
I rebuilt the unstable package against stable and set up a package
archive.
Neither of those is a satisfactory solution in that they're a little
risky and complicate maintenance for me, which costs my clients money,
which they'd rather spend on having me write web application code.
Are there enough Debian consultants out there for us to get organized
about this issue? Is there an appropriate way to use consulting revenue
as a motivator for package maintainers?
2: Re: Pseudopackages for rapid deployment of common configurations.
I'm guessing I'm not alone in reusing a lot of Apache configuration and
database schema every time I set up a new box for a client, a lot of
which is dependent on the presence of a variety of debian packages and
my own perl modules, postgresql-contrib functionality and other things.
Much of that isn't very appropriate for the user community at large, but
could probably be reused by other consultants if I ever get organized
enough to package it up and publish it. If others start doing the same
thing, not only do we get the benefit of sharing code and configuration,
we can hope that when we need to call for backup there'll be a handfull
of consultants out there already up to speed working in my customized
apache-mason-dbi-postgres environment or your apache-jakarta-jdo-mysql
environment. That makes it a lot easier to organize ad-hoc groups of
consultants to take on bigger jobs than they could individually.
3: Re: ad-hoc teams could handle bigger jobs
Speaking of ad-hoc groups, if there's anyone out there having trouble
nailing down contracts because you need more manpower, lack familiarity
with particular technologies, just aren't very good at writing
proposals, or whatever, I think this list is an appropriate place to
look for partners or subcontractors, or to post promising business
leads, or just ask for advice. If anyone out there is about to pass up
bidding on something that looks too big or requires someone on-site in
another city, or already has more work than they can handle, I'm sure
the rest of us would love to hear about it.
3: Re: getting Debian support from Rackspace, etc.
I occasionally wind up deploying on RedHat, because most managed hosting
outfits (like Rackspace) don't support Debian. I find this intensely
annoying, because I've become accustomed to the nice, smooth upgrades I
get with dselect. Can we organize petitions? Can we organize some sort
of commercial support collective (per Conrad Wood's suggestion)? Can we
refer each other to the handfull of ISPs that see things our way? Can
we pool resources and set up our own managed hosting environment?
4: Re: non-consulting revenue streams
Steady and non-personal-services revenue streams can be important to
small businesses, and there are a couple of ways in which solutions to
the above four issues could result in them. Managed hosting
environments for developers to deploy their clients on could provide
steady revenue for administrators. A consulting specific, subscription
based package archive could distribute income to contributing developers.
For the purpose of stabilizing revenue and also for obscure tax reasons,
it would be useful to find a way to re-characterize the service of software
development as pure R&D or as the distribution of software as a commodity,
assuming there's a way to isolate that activity in contrib/non-free
(which is distasteful) and/or somehow reconcile it with the GPL (which
may be difficult).
Obviously, some of this is drifting into subjects that tend to start
flame-wars, but maybe a detailed discussion about the role of money in
open source is an appropriate use of this list too, provided it stays
reasonably polite.
5: Re: requests for proposal
I'm sure we'd all like to see more requests for proposals. If that's
not appropriate for this list, there should be a debian-rfp list and/or
website as well, and the people on debian-consultants (including me)
might want to think about funding a little advertising for it.
A lot of that revolves around the same central concept: a federation or
collective of small, specialized consulting businesses that loosely
organize for particular purposes. Maybe this list would be a good place
to start one. I'm happy to help.
Good luck,
Cameron Ashby <cameron@clueinc.net>
http://www.clueinc.net
> Hi,
>
> This list has not received anything on-topic for at least a year, and what
> it has received was either spams, scams, or replies to those.
>
> Additionally, I don't see its purpose. :)
>
> Barring objections within one week, I'd remove the list.
>
> --
> 2. That which causes joy or happiness.
>
>
> --
> To UNSUBSCRIBE, email to debian-consultants-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: