* What is China Foo Camp?

China Foo Camp is a free, invitation-only event that brings together hackers, entrepreneurs, academics, venture capitalists, and technology influencers for an intense user-created conference about technology topics. The event combines learning, networking, and fun. Participants, who are experts and innovators in their fields, are also the presenters. The goal is to boost community and innovation, and to help the US sponsors to get to know the Chinese technology community better. China Foo, the first Foo Camp in China, is presented by IBM, O’Reilly, and the Institute for the Future (IFTF).

When is it?

The evening of Friday, November 9 and all day Saturday, November 10, 2007.

* Where will it take place?

In Beijing. We are still confirming the location for the opening session on the evening of Friday, November 9. On Saturday, November 10, 2007, it will be at the Beijing Landmark Towers Hotel (http://www.beijinglandmark.com).

* What is the format?

On Friday night, we’ll start with the popular Ignite format of quick talks–5 minutes, 20 slides, 15 seconds per slide–designed to stimulate discussion. These talks can be technical presentations or about how people use technology in their lives.

Video of Ignite events:
http://www.youtube.com/watch?v=QYW1bFsHEsg
http://www.youtube.com/watch?v=jDL7f4xFooU
http://www.youtube.com/watch?v=jDL7f4xFooU
A project led by MAKE magazine’s Bre Pettis at Ignite:
http://www.youtube.com/watch?v=YZJncWtr2JM

On Saturday, China Foo will follow the attendee-led format of Foo Camp, with several one-hour sessions happening concurrently. These sessions will be informal and participatory, not the type of prepared presentations that occur at typical conferences. Sessions can cover a wide range of technology topics.

At the beginning of the day, the entire group will gather and create the day’s schedule. People who want to lead a session will sign up on a large schedule grid that has a one-hour slot for each room available (example of a Foo Camp schedule board: http://www.flickr.com/photos/fallenpegasus/618582670). It takes about 20 minutes to fill in the board, and then people review it and go to the sessions that look interesting. Every hour, people move to the next session they want to attend. We’ll gather again at the end of the day for a short wrap-up.

For information about previous Foo Camps in the US and Europe, see:

Wikipedia entry: http://en.wikipedia.org/wiki/Foo_Camp
Wiki from Foo Camp 07: http://wiki.oreillynet.com/foo07
Wiki from Science Foo Camp 07: http://wiki.oreillynet.com/scifoo07
Photos from Foo Camp 07: http://www.flickr.com/search/?q=foocamp07
Photos from Euro Foo Camp 05 & 07: http://www.flickr.com/search/?q=eurofoo

* Who will be there?

We’re expecting about 100 people who work in fields such as web services, data visualization and search, open source programming, computer security, hardware hacking, mobile, GPS and other location technologies, gaming, alternative energy, and other emerging technologies.

Tim O’Reilly, founder and CEO of O’Reilly Media, and Rod Smith, VP, Emerging Internet Technologies at IBM will be attending from the US. An influential group of people who are knowledgeable about the technology world in China are helping IBM, IFTF, and O’Reilly with the event. This group includes:

Liam Casey, PCH China Solutions
Jeff Chen, Maxthon
Tim Chen, VIA
David Chen, Oregon Venture Partners
Aaron Farr, Apache Software Foundation
Li Gong, Mozilla
Erik Hartmann, Google China
Rania Ho, Ogilvy Digital Media
Keso Hong Bo, blogger
Bunnie Huang, Chumby
D.J. Jiang, XOOPS
Amy Jiang, Canonical
Kaiser Kuo, Ogilvy Digital Media
Isaac Mao, UCI, blogger
Sean Moss-Pultz, Open Moko
Bj縭n Stabell, Exoweb
Stephen Walli, consultant
Frank Yu, MSRA, Advanced Technology Center
Sunny (Xi Xi) Chen, IBM developerWorks China
Dan Brody, Google China
Ruan Ying, Oak Pacific Interactive
Mike Meng, CSDN
John Turek, IBM China Development Lab
Xin Sheng Mao, IBM China Development Lab
Li Shao Yu, SINA.com
Alan Chen, The9 Computer Tech. Consulting
Ally Yang, Hands-On Mobile
Fang Gang (Forrest Fang), SOHU.com
Xiao Li, ChinaUnix
Pan Hai Dong, Hoodong.com
Wang Xing, Xiaonei.com
Sam Flemming, CIC DATA

* What do I need to do when I attend?

Participate! If you have something you want to share, or ask others to help you explore, sign up to lead a session. You don’t need to be an expert or have a polished presentation about your session topic, but you do need to bring ideas, questions, and problems about it for the group to address. While we won’t have enough time slots for every person to lead a session, participants are vital to the success of China Foo, so attend sessions and contribute actively to the conversation.

Introduce yourself to others. People are the most important part of China Foo, and the more you meet new people and engage them in conversation, the more rewarding the event will be for you and everyone else.

* Why is it called China Foo?

“Foo,” is a word used by programmers to represent variables such as data, functions, and commands. O’Reilly Media realized that it could also stand for “Friends of O’Reilly,” and named its 2003 event for Foo Camp. There have been 10 Foo Camps in the US and Europe since 2003.

From O’Reilly Media, Inc.

Friday March 02, 2007
By: Bruce Byfield

Payment, of course, is not new to FOSS communities. Companies such as IBM, Novell, Red Hat, and Sun Microsystems have employed developers to work on FOSS for years. However, the issue has received renewed attention in recent months because of the reaction to a project called Dunc-Tank within the Debian community. Dunc-Tank made headlines in the FOSS world when it proposed paying the two Debian release managers for one month each to speed up the distribution’s next release. Despite widespread opposition that included heated discussion, a parody site, and an unsuccessful attempt to impeach Anthony Towns, the Debian Project Leader and a member of Dunc-Tank, for conflict of interest, the proposal for funding went ahead.

The Debian community is still discussing Dunc-Tank, and the arguments on each side should be of interest to the greater FOSS community. To Dunc-Tank supporters, the issue is straightforward: give select members of the community reasonable but not excessive funding, and they can concentrate on their FOSS contributions full-time. To detractors, such payments seem a form of favoritism. Debian developer Joey Schultze, for example, states as a fact that Dunc-Tank “has demotivated a lot of people.” Others cite theoretical research by Luis Villa of GNOME that seems to indicate that payment reduces volunteers’ “sense of self-determination and self-esteem,” making them less likely to participate “because they want to help others, or because it is fun.”

For all the attention that this discussion has attracted, the trouble is that, despite the practical nature of Dunc-Tank, the looseness of its goals means that the discussion on both sides tends to be theoretical. For those with a broader picture of payment in FOSS project, the issues are more complex and context-dependent.

Bounties

One of the most frequently mentioned forms of payment is a bounty, or a reward posted for a specific programming task. In most cases, bounties are for small, specific pieces of work, and are usually worth only a few hundred dollars to those who claim them.

The leaders of projects contacted by Linux.com were unanimous in urging caution about bounties. Although none had a set policy against them, all had learned from experience to be cautious about them. Mostlly, their arguments were similar to those advanced by opponents of Dunc-Tank. Frank Hecker, executive director of the Mozilla Foundation, suggests that the problem with bounties is that they are too contrary to the spirit of volunteerism on the one hand, and not large enough to motivate people on the other. If you are given cash, particularly for development that you might do anyway, Hecker suggests, then the development “becomes work rather than something you’re volunteering to do.” In other words, it risks becoming an obligation rather than an interest, or something done out of a sense of enthusiasm and commitment.

Max Spevack, chair of the Fedora Board, agrees, adding that “It also feels kind of wrong to think about a self-contained piece of [a project] and assign it a value.” Often, doing so requires an executive decision, which again makes the development seem more like ordinary employment.

For such reasons, Hecker maintains that, of all forms of compensation, “Paying bounties is the least likely to succeed.”

This conclusion seems supported by the experience of the now-defunct Bounty Country site, which was briefly run by the developers of Democracy Player. Intended as a site where projects could post bounties, Bounty Country attracted few postings. Democracy Player itself managed to have one successful bounty, but several others were never completed. Nicolas Reville, a Democracy Player developer, suggests that the site might have been more successful as part of a news site or within a specific project, but its lack of success is consistent with the observation of others.

A related but lesser-known type of payment is the anti-bounty, in which developers seek sponsors for work they want to do. According to Boris Mann of Bryght, who has completed at least one successful anti-bounty within the Drupal community, anti-bounties avoid many of the problems of normal bounties. Because they are posted by developers, Mann says, anti-bounties tend to be more realistic about scope, requirements, and costs. More importantly, because a developer is already interested in a project for which he posts an anti-bounty, Mann suggests that payment is less likely to destroy motivation or morale within a project, and more likely to result in a higher rate of completion than ordinary bounties. However, the concept does not appear widespread enough to draw definite conclusions from.

Payment in kind

A second compensation option is payment in kind, which consists of donations from a project to help key contributors advance their work, such as hardware or trips to conferences.

Leaders of large FOSS projects sound as enthusiastic about payment in kind as they are wary of bounties. The difference, Hecker says, is the difference between buying someone a $500 hard drive and giving them $500 cash. “It’s like a gift,” Hecker says. “If you give somebody a birthday gift that’s cash rather than giving them something they can actually use, it’s typically seen as a little more impersonal.” In the context of a FOSS project, payment in kind is also a way of singling someone out — of giving the recipient credit for work already done while enabling him to improve his contribution. In short, it fits into the FOSS culture in a way that cash does not.

Spevack, who explains that Fedora often funds contributors’ expenses to attend conferences like FUDcon, says, “It seems a smarter investment of money because it helps people while also building the community. It seems more win-win [for both the project and the recipient] than just saying, ‘Here’s some money. Thank you.’”

Payment in kind does have the potential to cause resentment among those who do not receive it, but Spevack suggests that, given the meritocracy that prevails in most FOSS projects, it generally should not. “You could ask anyone in the community who the leaders are and everyone would give the same names,” he says. “So it doesn’t create any ill will.”

Just as importantly, because payment in kind is a gift that recognizes a significant contribution, it does not trigger any of the implications of employment, especially when it takes the form of sponsorship for a conference. Talking of the recent FUDcon, Spevack suggests that those whose way to the conference was paid “were energized and pumped up” by the experience of meeting their peers face to face and that “a lot of good work” was done at the conference.

Grants and employment

For Spevack, a different approach, that of grants or offers of employment, is simply a larger version of payment in kind. When Red Hat has open jobs, particularly ones that involve working with Fedora, “we fill them by hiring someone who has been part of the Fedora community,” Spevack says. “And to me that is a perfectly reasonable thing to do for a lot of reasons: they don’t need to get up to speed, they’re already there, and it’s a way to show that we appreciate the work that people in the community do. Things like buying people a ticket to FUDcon are a smaller example of that.”

Hecker points out that, in addition to being a reward for a volunteer’s contributions, grants or employment can also be a way of encouraging development in areas that are being overlooked. For example, the Mozilla Foundation has given grants to encourage the development of accessibility features in Firefox and Thunderbird.

“Unless you’re disabled yourself,” Hecker says, “You usually don’t think much about accessibility issues. So we don’t have a lot of volunteer contributors. What we consequently try to do is build a group of contributors who are already involved in Mozilla one way or the other and get them interested in accessibility by offering them grants.” In at least one or two cases, receiving a short-term grant to work on accessibility has encouraged volunteers to continue with the work after the grant runs out. Grants, Hecker says, “get people interested in work they wouldn’t otherwise be interested in, and they can justify it to themselves because they’re getting compensated for it.”

Choosing the type of payment

The key to introducing payment into FOSS projects, experts agree, is to consider the context. When Google receives funding requests, says Chris DiBona, open source program manager at Google, “Our response is always the same: What good will the money do? Show us how the money helps the project and why you are the one to execute the plan.”

“There isn’t one answer,” DiBona adds. “For every project, you have to consider if money can help at all.”

For Hecker, the important aspect is the motivation of individuals. Although he advises other projects to “avoid money for bug fixes” — a common type of bounty — he goes on to say that the appropriate form of payment depends on the recipient’s preferences. Using the Mozilla Foundation as a example, he says, “A lot of people who are Mozilla volunteers consciously decided that they like it better as a volunteer. They feel motivated as a volunteer, and they wouldn’t necessarily feel motivated as a full-time employee.” For such committed volunteers, payment in kind is likely to be the most appropriate choice if any sort of compensation is given. For others who are more career-minded, a grant or employment is probably a better choice.

“This idea that money automatically kills open source projects is not really true,” Hecker says. “Certain types of schemes can kill motivation, but I don’t think it’s the case in general that introducing money into open source projects in and of itself is going to cause problems. It’s all in the way that it’s handled and in the way that it’s structured.”

FOSS

Tuesday March 13, 2007
By: Joe Barr

When I first began programming in the 1960s, testing was done to prove that code worked. The first big change to that approach came with IBM’s Black Team, which took the opposite tack and tried to break the code — an approach that was radical at the time. In the next popular phase, the color of testing changed, and white box testing, in which you know what a program is supposed to do and check that it does it, was all the vogue.

Those approaches come from the world of closed source, proprietary software. Testing in the FOSS world is different. For one thing, bug reports can come from anywhere, not just from a team assigned to test the product. The transparency of the code invites everyone to explore.

Former Debian Project Leader Martin Michlmayr advises, “If you want to test something, run the latest version. This may sound obvious but apparently it’s not. If you run Debian, upgrade to unstable and maybe pull in some packages from experimental. For other software, try the latest version from the project’s version control system and see what breakage you can find.

“You have to be creative, and you have to be quick. You’d be amazed how many bug reports we get for issues that have already been fixed. It’s therefore important to run the latest version and to check for bugs in the bug tracker. If you cannot run the latest version all the time, at least try to verify whether the issue you see still applies to the latest release.

“Regarding the bit about being creative: we get a lot of bug reports in Debian and really appreciate them. But there are many issues that many people find, and that can be found easily. What really helps is if someone is creative about finding things, or maybe just very patient. You don’t necessarily need to read source code, although this may be a good exercise for someone trying to learn how to code. Someone could also take the manual or man page of a program and compare it with the actual behaviour — I bet there are plenty of examples where the docs are out of date.

“Try to do unusual stuff with the software or test it in unusual environments, such as especially slow hardware or uncommon platforms.”

In addition to Michlmayr, I got tips from GNOME bug master Luis Villa, Debian bug-finder extraordinaire Dan Jacobson, and Dave Freese, author of several ham radio applications for Linux. They came up with these tips for better testing:

* Run the latest version of the software you’re testing
* Check for duplicates before filing a bug report
* Include enough information in your report so the issue can be reproduced
* Don’t apologize for your language
* Use a bug tracking system of some sort
* If possible, write automated unit tests
* If possible, use the code you’re testing under real-life conditions
* Use automated crash reporting tools
* Become familiar with the tools that will be used to compile, link, and test the code
* If possible, maintain a separate environment for testing
* Keep a few back revisions of the code to track when errors appear
* Describe as completely as possible the conditions leading up to a fault
* Your “newbie impressions” are critical — report everything you see
* Be patient with developers

Michlmayr also suggests several pages for additional reading:

How to Report Bugs Effectively
Bug Writing Guidelines
How to Write a Useful Bug Report
Lessons from GNOME Project QA

Testing is a great way for non-programmers and even non-geeks to contribute to the greater good. Get involved with your favorite free software projects and send them a bug report or two.

FOSS

请问类别的顺序要如何更动?

比如贵站的分类为

Blogging

CMS

综合

自由软件与开源社区

顺序想改成

综合

Blogging

自由软件与开源社区

CMS

Jakob Nielsen, September 5, 1999

A reputation manager is an independent service that keeps track of the rated quality, credibility, or some other desirable metric for each element in a set. The things being rated will typically be websites, companies, products, or people, but in theory anything can have a reputation that users may want to look up before taking action or doing business.

The reputation metrics are typically collected from other users who have had dealings with the thing that is being rated. Each user would indicate whether he or she was satisfied or dissatisfied. In the simplest case, the reputation of something is the average rating received from all users who have interacted with it in the past. Other systems are possible, as discussed below.

Current Reputation Managers

* eBay (auction site) keeps reputation ratings for all the people who offer things for sale on the site. After buying a collectible in an auction, you can go back to the site and rate the seller for prompt shipping and whether the physical item actually matched the description in the auction. This is the most literal of the current reputation managers: eBay literally keeps track of the reputation of each seller. Prospective buyers can feel safe bidding on items from people they have never heard of: if the reputation ratings show that many previous buyers were treated well and thought that the textual descriptions matched the actual collectible, then the seller is almost certainly honest and worth dealing with. Also, sellers are highly motivated to offer great service to every single buyer: a single customer with a bad experience will ruin a seller’s perfect reputation rating and multiple bad experiences (quickly followed by negative ratings) will put a seller out of business for good.
* Epinions (electronic opinions) is the most interesting new reputation manager: it collects user feedback, reviews, and ratings for a wide range of products and services - all the way from laptop computers to museums in New York. When you want to buy something, you go to Epinions first to check the reputation of the different models you are considering. You can also check the reputation of the manufacturer’s other models: do they in fact work as advertised or do people experience problems after owning something for awhile? Despite all the hype about ecommerce, it is so hard to buy anything on the Web today because you never know whom to trust. It has close to zero value when somebody who sells a product claims that it is great or that it meets certain needs. Having an independent service to guide customers to good products and warn them against lemons will be one of the most important enablers of ecommerce.
* Google (search engine) maintains a reputation rating for every site on the Web and uses this data to sort the return set for searches to place the highest-quality hits on top of the list. Google derives its estimate of a website’s quality from the number of other sites that link to it (as well as some fancy math that gives greater weight to links from more important sites and less weight to links from minor sites).
* Go (search engine formerly known as Infoseek) is adding a human touch to the service in the form of so-called Guides: individuals who are experts in a certain area and provide Go with their ratings and comments on sites within that area. These comments combine to form the reputation of the sites. But more interestingly, the Guides themselves are rated for the quality and value of their contributions and rise through the ranks based on these reputation metrics. More advanced Guides (with high ratings) are responsible for larger areas of the service and have some form of management responsibility for lower-rated Guides.
* Slashdot (discussion board) lets users rate the usefulness of the various comments in a discussion thread. When reading a thread, you can set an option to show only the N highest-rated postings, thus significantly increasing your experienced signal-to-noise ratio. Unfortunately, the ability to filter out poorly rated comments is not turned on by default, so only diligent users who study the slightly confused user interface will discover this useful feature. Slashdot also awards regular users “karma” points which are a true reputation manager: if you have done well in the past, you have high karma, which again means that your actions carry more weight.
* Third Voice is an annotation service that allows users to write comments on any Web page in a transparent overlay layer that is shown to other users of the service. These annotations are not under the control of the website owner since they come directly from the Third Voice server. The annotations combine to a kind of reputation for each site: for sure, they can be used to warn unsuspecting visitors about shoddy products and false or misleading advertising. Since the annotations are natural language text, they are less useful for finding the best sites or doing any kind of computations.

Reputation Manager Problems

When collecting feedback from random people, the results can be random as well. Third Voice suffers from the traditional flaming problem of Usenet as well as the low signal-to-noise ratio of chat rooms. You never know whether the person who posted a comment actually knows what they are talking about or whether you are wasting your time reading some bozo’s rantings.

Amazon.com pioneered the idea of customer reviews, but has been plagued by unreliable reviews (an author’s enemies post a flood of negative reviews; followed by the author’s friends who post glowing reviews). Also, users never know whether they can trust reviews that are posted as part of a site that profits from selling the product.

Google and eBay avoid these problems by aggregating ratings across a very large sample. Google also benefits from the fact that Web authors are reluctant to include a link unless they actually want to guide users to the destination site. Even if there are some spurious links, they vanish when doing statistics across a billion pages with several billion links. eBay collects reputation rankings from the specific people who actually bought something from a seller, thus avoiding comments from random users.

Epinions is a double reputation manager: not only does it rate products and services, it also rates reviewers. After users have read a review, they are encouraged to vote on whether they found the review useful or not. In showing lists of reviews to users, Epinions places the most highly rated reviews on top, thus assuring that readers will focus on the best content. Also, reviewers build up status depending on the user feedback on all their reviews, meaning that people will be reluctant to contribute low-quality reviews to the service. A final interesting twist is that users earn a micropayment every time somebody reads one of their reviews. Thus, people are motivated to write valuable reviews, not just to gain a high reputation rating, but also to earn money.

Future of Reputation Managers

I see reputation managers as core to the success of the Web. As we get more sites, more content, and more services online, users need a way to learn what is credible and useful. Quality assessments must become an explicit component of most Web user interfaces. It is not sufficient to list millions of items for sale and leave it to the user to determine what they need. Everybody is not equal.

Reputation managers overcome the complaint against shop bots that they purely focus on price and ignore customer service. Once it can include an independent source of rating data, a shop bot can show users:

* what they can buy
* where they can buy it
* how much each option costs
* how good each option is
* what level of customer service to expect from each vendor (e.g., average fulfillment delay, whether shipments usually arrive in good shape, whether the vendor is decent in dealing with returns, etc.)

Reputations managers will thus cause a renaissance for good customer service: the way a company treats any individual customer will be fed directly back into its reputation ranking and will influence its future sales.

Investors will finally get a handle on intangible concepts like “brand equity” and “goodwill”: just go to the reputation manager and look up how customers rate the company and various aspects of its service. If a company does something wrong, its reputation statistics will rapidly drop, immediately followed by a massacre of the stock valuation. If a few Belgians become sick from drinking a soft drink, then the manufacturer may lose billions on Wall Street five minutes later. Another reason reputation managers will contribute to highly improved product quality and customer service.