Re: removing debian-consultants list
re:
1)
We actually do a very similar thing to yourself. We packaged/repackaged a
few of the debian
sources and provide them on our mirror. I would very much like to share
some/most/all packages
with others and would be quite happy to provide passwords to access our
mirrors. (As long as I don't
find it requiring 100s of Megabit Bandwidth suddenly ;-) )
We ought to discuss the structure of such mirror carefully, though.
2)
I actually began streamlining debian-server-installations. I want to end up
with a boot-cd from our network that
initially partitions a harddisk, then bootstraps the installation and
doesn't bother me until it has finished installing.
Then I have packages like 'lemon-office-server' or 'lemon-webserver' which
depend on the appropriate packages like samba/squid/exim/courier or
apache/tomcat/cocoon and so forth.
3)
Precisely my point, just phrased better - thank you.
At this point, is anyone skilled in, or has done already, written a
support-contract for fixed-fee network maintenance?
3)
Tricky because it depends on location too. You don't want to host your
server in Australia if most of your clients are in England. Therefor it is
not going to be a very efficient pooling of resources here ;(.
We haven't got a good solution for this yet either.
4)
We tend to develop tools/software in our company because either
a) it makes our job easier
b) we know we can sell it.
as far as b) is concerned, we usually sell the software until we made a
reasonable profit or at least achieved break-even point. After this, we
release a later version under GPL.
We also develop software on microsoft windows which clients don't seems to
mind paying for ;)
This windows software is not GPL, but I don't really mind giving out a
license and source to other technicians/consultants for free.
----- Original Message -----
From: <cameron@clueinc.net>
To: <debian-consultants@lists.debian.org>
Sent: Wednesday, June 04, 2003 2:00 AM
Subject: 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
>
>
> --
> To UNSUBSCRIBE, email to debian-consultants-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>
>
>
Reply to: