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.
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.
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.
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.
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.
A1.g -- Training
We hope to kick off a series of reputable Python training courses around Europe.
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?
< We only got the aggrement with PythonLabs to go ahead with this because we promised them _less_ work, not _more_. >