O'Reilly is trying to connect with the various open-source communities, such as the Python and Perl language groups, but also groups like the BSD Foundation. The criteria for whom to contact was partially based on those groups having some form of formal organization, similar to the Apache Foundation.
O'Reilly is in the very early stages of trying to discover how the groups can work together, with no actual kick-off until January 2007. The phone call was primarily to solicit ideas than to propose specific actions.
A Common Documentation Workflow
Shane said that O'Reilly was hearing a lot about how one problem that open-source communities face is poor documentation and that there is a strong need for documents being available in multiple languages. Teachers in certain countries are saying, for example, they could not use the BSD Book because their students lacked sufficient english to follow it.
So one goal might be for O'Reilly to provide translation coordination, and perhaps push for a single common documentation format, along with some workflow coordination of the global documentation scene, to try to raise the quality of documentation. Details are vague and certainly getting the entire open-source community to agree on one format would be a herculean challenge. Still, O'Reilly said they have a history of embracing challenges.
Part of the idea is to try to involve documentation contributors beyond the original developers, by adopting a format/mechanism that is friendly to technical writers, educators and college professors. I suggested something like reStructured text, which Shane was already familiar with. After researching the One Laptop Per Child project, I might now propose the derivative, Crossmark text, which supports multi-page documents.
It came up that people will often choose a programming language by whether there is documentation in their native language rather than purely on the merits of the programming language itself. This led to ideas of other ways to advocate the use of a programming language.
A Problem-Centered Tool Selector
One idea I proposed was a web portal of programming language concepts, with very good explanations and links to source code examples in a variety of programming languages. Shane mentioned the scriptome, a cookbook of of Perl one-liners for bioinformatics data processing tasks.
My work in advocacy has brought to my attention the need to focus on the domain or problem first, and then show how a technology can meet those needs. So I proposed a portal with some kind of sophisticated lookup/navigation engine, where someone with a problem could identify those programming languages with strengths in their area, perform comparisons among languages/frameworks and eventually decide on the toolset to use. I've already done a bit of work along these lines.
Shane thought this might have some possibilities, that we could identify a handful of problem areas and, working with a few members from each open-source community, come up with a handful of recipes to present. Then if it really is a good idea, encourage it to take off from there, else let it fade away.
It also occurred to me that such an arrangement might encourage the improvement of languages, by shining a light on select areas. A bit of friendly rivalry where upon discovering a gap in the solution space of language A but not in language B, that the community for language A might then work to fill that gap.
Registry of Speakers
Continuing our brainstorming on ways for O'Reilly and the open-source community to work together, I brought up the recurring problem that user groups often have of finding speakers. And while some speakers/topics are language-specific there are also those that cross language boundaries. So how about putting together some form of speaker registry, keyed both my open-source project and geographical area. This way user group organizers can search for someone to visit their group. And since there are also traveling speakers looking for engagements, such a solution should allow a speaker to visit the portal and indicate the areas in which he can speak and the dates when he will be in certain cities, to locate an audience. This way he can optimize his time, find receptive audiences of which he was unaware, and perhaps expense his trip on his taxes.
Targeted Book Release Notices Filtered by Community
Another idea is for the publishing industry to improve the way in which it communicates with its readers. It was unclear to Shane if O'Reilly already had such a system in place, or if so, whether it had all the functionality I'm about to describe.
The idea is for publishers to provide RSS feeds of current and future releases, appropriate tagged with publication date, programming language and so forth. Then the various Python, Perl and other websites could subscribe to the feeds and stay current on releases. At the moment many rely upon volunteer labor to manually post book information on their sites. Such a feed system should also provide for book reviews, and the ability of a person to subscribe to a feed by a particular author. Basically something a bit like a distributed form of the review system on Amazon.com's website.
This is nothing new and we're sure bits and pieces of this exist to some degree. It just needs to be standardized and mainstreamed. The approach helps publishers spread the word about their product by leveraging the open-source portals which have their own, focused traffic. And the portals benefit because their visitors want to know what new releases are coming in the specific area of interest.
Certainly publishers, including O'Reilly publish newsletters, including a mailing list of releases, but that material often mixes it all together, sending Java book notices to Python programmers and vice versa. It also usually is complete PR spin and lacks reviews by the community.
Alternative Ways of Publishing
We also discussed O'Reilly's move toward print-on-demand, and how it will increase the diversity in printed reading material, providing an outlet for subcommunities too small for a traditional book run. One trick will be to find ways to market those creations, since your normal publicity effort would be too costly. It will be important for O'Reilly to cheaply spread the word to the specific audience for a topic, and being able to RSS-stream release, review and author information to specific open-source portals would be a step in this direction.
And I brought up the challange of open-source projects like Zope 3, where the underlying software changes faster than a printed book can track. A solution is 'iterative editing', where a publisher keeps a book hot and streamlines the publication of future editions every 3-6 mos. However it also requires the open-source community to feed updates to the author/publisher on a near continual basis so the frequent editions are current.
Expanding the Pool of 'Non-Programming' Programmers
We continued on talking about how to achieve "programming for non-programmers", to draw in those who are not (and do not want to be) professional programmers, such as scientists and teachers. I don't have any specific project suggestions in my notes, other than my own strong desire to reach out to non-programmers, the establish basic software literacy. Shane mentioned that O'Reilly believes there is an incredible audience of open-source that is being ignored by traditional IT marketing.
In Closing - A Few Guiding Principles
- focus PR campaigns on those who are ignored, such as non-programmers
- the community will never agree on one format, so adopt several good ones and support mechanical conversion.
- to enable iterative editing/release, try to avoid the use of one-way conversion tools re print layout
No comments:
Post a Comment