Introducing the Python Business Forum

[Andy Robinson]

We would like to take this opportunity to introduce you to the Python
Business Forum. Recent discussion among the leaders of a number of
businesses which develop using the Python programming language has found
a business case for closer collaboration.  A more formal organisation
was indicated.  Thus was born the Python Business Forum: a trade
organisation
set up to coordinate official formal business of the Python Business
Community.

The PBF has a webpage, currently: http://pbf.nuxeo.org/

where you can find:

a) the minutes of the formation of the PBF
b) the board minutes of the PBF
and
c) (the good part) the Bylaws of the PBF.

In addition, a partial list of Projects already planned by the PBF will
be arriving as soon as each Special Interest Group has selected its
own Chairman.  Membership pre-requisites, and instructions on how to
join are found there also.

In the hopes that it will encourage membership in the PBF, we hereby
present the 'preemptive FAQ'. This is simply a the list of questions
and answers that we expect people will ask us.  The FAQ currently
lives here:

We will, of course, update it with answers as we get real questions,
frequently asked or not.

					Laura Creighton
					Secretary, PBF

---------------------------------------------------------------------------

Q1:  What are some projects currently in the scope of the PBF?

A1.a -- Creating build and test farms and maintaining a stable
        business release of Python

  A problem that faces many of us is the certification of the Python
  distribution on different platforms, and the certification of our products
  with the Python distribution of different platforms. Through the PBF we
  could share the hardware and personnel needed to maintain a range of
  platforms that would be very expensive for each one of us to keep in
  operation.

  The current 6 month release cycle that Guido van Rossum and the Python
  development team prefers is far too quick for most businesses to keep up
  with.  It puts undue strain on a company to re-certify your products every
  6 months and your customers get unhappy if you make them upgrade too
  frequently. It also means that there are multiple candidates for
  "best version to install" at one single time.  Note that some businesses
  don't find it a problem, but at least 75% of those we have spoken with do.
  The consensus is that an 18 month release cycle would be better, for
  business.

  But this release cycle is far too sluggish for language developers.
  Their needs are for quick release cycles with freqent changes and
  constant testing.  This attracts the bright, young developers and
  avoids the problem of 'force-feeding the Python' in order
  to make a release date, then idling for months.  But the more
  releases one has, the harder it is to make sure that crucial bug
  fixes are ported to an increasing number of release candidates.
  The current process requires a hero, who needs things so badly
  himself that he is willing to do whatever it takes to get a
  bug-fix release of whatever version out the door.  We can improve
  on this process.

  But, it falls on us, the Business Community, to make sure that
  we have something that is stable and which sends a single, uniform
  signal to the market. This means that we need to backpatch bugfixes
  and significant performance improvements from the development release
  of Python to the business release and certify it on a wide range of
  platforms.  We may also want to backport new features that do not break
  any code. For the core language, this is a sensitive issue, which should
  require a strong consensus before anything is done, while for libraries
  it is much less sensitive though of greater importance to some of us -
  'service packs' are quite possible.

  GvR has agreed to flagging such a release and sending such market signals.
  He would designate 2.x.y as "the release that wears-a-Tie, as endorsed
  by the Python Business Forum members....".  In return, he wants
  us to take on the burden of backporting any critical fixes; and is
  keen on the idea of a build farm where pythonlabs' code can be tested
  against a wide variety of real world apps and extensions, as well
  as the Python test suite.

  We have already located a superb resource with over 30 Unix machines to
  use as the build-and-test farm for Python, which we dub the "Snake Farm".
  A Separate Snake Farm document will be released early next week (week 20
  of 2002).

-------------
Status:		SiG established.  Chairman Laura Creighton


A1.b -- Creating a network of agents

  There is a business case for using other companies that rely on Python
  as agents for your products and services. Most of our companies are small,
  with few resources to reach an international market. By co-operating we
  can all extend our markets without heavy investment. The fact that we
  are all using Python should make us all able to explain why the underlying
  technology makes the products we are selling better. We also have the
  base knowledge to provide additional services and consultancy to our
  local customers. This limits the need for transfer of know-how to the
  product itself.

-------------
Status:

A1.c -- Creating a Consulting and Referral Network of Resources

  Some of us have the problem of having more business than we can handle,
  while others have idle resources, or would like to use some of our
  resources for generating short term revenue in conjunction with working
  on development that produces revenue in a longer perspective. The PBF
  would provide a forum where requests and availability could be announced,
  with reasonable confidentiality.

-------------
Status:

A1.d -- Escrow and Contract Services

  The PBF has a bank account and a professional accountant.

  When dealing with small businesses or with governments there is a
  significant risk of non- or late payment; likewise small consultants
  find difficulty in receiving work because their potential clients
  worry that the work may be unsatisfactory.  The PBF will provide an
  escrow service so that vendors can insist a deposit is paid before
  starting work, to be paid out under agreed conditions.

-------------
Status:

A1.e -- Providing the group of companies a better media profile

  Most of us are small companies with little attractiveness to journalists.
  Python and the Python community also lack the factors that make media
  want to talk about us. A commercial organisation that stands behind an
  OpenSource language would be something new and interesting to report on.
  By managing this initial news value well, we can then build a lasting
  media interest for Python as well as our companies and products. Once the
  productivity advantages of Python are made clear to the general press
  (as opposed to the computer press), they will need success stories to
  exemplify why Python works so well.

-------------
Status:

A1.f -- Organising business-oriented conferences

  There is considerable interest from various government bodies as well as
  from large corporations in leveraging the advantages that using OpenSource
  bring. However, we are usually too small as individual companies to get
  the big organisations to listen to us. By arranging conferences where
  we mix the presentation of our individual products with presentations on
  the principles of how OpenSource works and why Python is a great
  development language, we can attract decision-makers from these
  organisations, thereby giving us the chance of conducting business with
  them directly, as well as creating the base-knowledge of our existance,
  a prerequisite for getting any big contracts at all.

  Examples of groups that we would like to target with such conferences are
  various offices of the EU Commission, Central Government Agencies across
  Europe and the largest corporations in industry, finance and transport.

-------------
Status:

A1.g -- Training

   We hope to kick off a series of reputable Python training courses
   around Europe.

-------------
Status:

Want more? Join the PBF and form your own SIG.

-------------
Q2. -- Why Now?

A2.  Because the time is right.  The Forum's founder members have long
     experience in the software industry and are determined to create a
     professional organisation which grows the commercial market for
     Python software.

Q3. -- Come Again?  I didn't understand the last part.

A3. Ok, we will now attempt to answer both in the dialect of English
    used by business, and annotated in the dialect used by hackers.
    Here's the hacker for Q2.

    < The Timbot suggested that if the business community was unhappy
      it could jolly well do something other than complain.  The
      first thing we did was organise. >

Q4. -- This looks like a European Organisation to me.  Correct?

The initial focus is European, for efficiency because the founding
companies are located there, but this is a full-fledged international
organization.  Local regional sub-networks of the PBF are encouraged.

     < Trying to get tons of work done when your members are spread
       over the globe is a real pain.  We've done it.  Every time
       you need consensus, somebody is bound to be asleep.  Unless
       you have tremendous discipline, your schedules slip.  We
       know how to run international projects with members in various
       time zones, but the core team does not want to commit itself
       this way right now. >

Q5. -- Why isn't the PSF doing this?

The PSF is a developers group, which is concerned about the integrity
of the Python Language, which is an entirely different function.  It is
likely that many companies will be members of both organizations.

      < We all want better Pythons, but we are bringing a completely
        different skill-set to the mix.  We want different things, and
        know how to get them.  We don't want to discuss nerdy things
        here, but rather things that bore nerds to tears.  Trust me
        on this one -- if the phrase 'marginal product' causes you
        to think 'badly made junk' and not 'the rate at which output
        increases as the quantity of that input increases, all other
        inputs held constant', then you probably do not wish to be
        the representative that your company selects for the PBF.

        Conversely, we do not want to be involved with the technical
        decisions about the design of Python.  We don't care.  You give
        us a Python, and we will make a Python-in-a-Tie out of it, and
        that's all.  Hacker-PBF members will have to leave their
        propeller-hats at the door before arriving for our meeting,
        because if the talk gets technical, we will declare such
        chatter out-of-order and resume with the issue at hand. >

Q6. -- Isn't this a bit formal?

No.  It's _extremely_ formal.

Q7. -- Why did you form the PBF before announcing it?

We are results-driven, commercial enterprises.  We consider the forming of
the society as a formality. The things of real interest will be happening
in the SIGs.

	< If we had done that, the debate about whether to do this
          would _still_ be going on!>

Q8. Won't this hurt ActiveState and other companies reselling Python?

No.  The only thing that will change is that they will have a Python which
has been tested on more platforms to start out with.  Indeed, they will be
free to spend more time in the creative efforts which results in product
differentiation, and less on that necessary but tedious work of testing
and bug-fixing.

Q9. Won't this make more work for Guido and the PythonLabs team?

No.

   < We only got the aggrement with PythonLabs to go ahead with this because
     we promised them _less_ work, not _more_. >