Hello, O.k. below are some comments. Your article although well written has a distinct, from the community perspective ;) and I think there are some points from the business side that are missed.
--- Employees working in open source communities have two bosses -- the companies that employ them, and the open source community, which must review their proposals and patches. Ideally, both groups would want the same thing, but often companies have different priorities in terms of deadlines, time investment, and implementation details. And, unfortunately for companies, open source communities rarely adjust their requirements to match company needs. They would often rather "do without" than tie their needs to those of a company. --- Employees don't have two bosses at least not in the presentation above. In the community the employee may choose to do it the communities way or not. That choice is much more defined within a Boss purview. A companies priorities have a priority that is very powerful that the community does not and I believe should be reflected in a document such as this. To actually feed the employee. There is a tendency for the community to forget that every minute spent on community work is a direct neglect to the immediate (note that I say immediate) bottom line. That means that priorities must be balanced so that profit can be made, employees can get bonuses and god forbid a steady paycheck. --- This makes the employee's job difficult. When working with the community, it can be difficult to meet company demands. If the company doesn't understand how the community works, the employee can be seen as defiant, when in fact the employee has no choice but to work in the community process and within the community timetable. By serving two masters, employees often exhibit various behaviors that make their community involvement ineffective. Below I outline the steps involved in open source development, and highlight the differences experienced by employees involved in such activities. --- The first paragraph seems to need some qualification. An employee is hired to work at the best interests of the company, not the community. Those two things may overlap, but that is subject to the companies declaration. If the employee is not doing the task as delegated that is defiant. I am suspecting that your clarification would be something to the effect of: When a company sets forth to donate resources to the community, it can make an employee's job difficult. It is important for the company to understand exactly what it is giving and the process that gift entails. Or something like that. I take subject to the term serving two masters, I am certainly not the master of my team but that may just be me. --- Employees usually circulate their proposal inside their companies first before sharing it with the community. Unfortunately, many employees never take the additional step of sharing the proposal with the community. This means the employee is not benefitting from community oversight and suggestions, often leading to a major rewrite when a patch is submitted to the community. --- I think the above is not quite accurate. I see few proposals actually come across to the community either and those that do seem to get bogged down instead of progress being made. The most successful topics I have seen are those that usually have some footing behind them *before* they bring it to the community. --- For employees, patch review often happens in the company first. Only when the company is satisfied is the patch submitted to the community. This is often done because of the perception that poor patches reflect badly on the company. The problem with this patch pre-screening is that it prevents parallel review, where the company and community are both reviewing the patch. Parallel review speeds completion and avoids unnecessary refactoring. --- It does effect the perception of the company. Maybe not to the community but as someone who reads comments on the patches that comes through... I do not look forward to the day when I have a customer that says, didn't you submit that patch that was torn apart by... --- As you can see, community involvement has unique challenges for company employees. There are often many mismatches between company needs and community needs, and the company must decide if it is worth honoring the community needs or going it alone, without community involvement. --- Hmmm... That seems a bit unfair don't you think? The people within the company are likely members of the community. It seems that it makes sense for the community to actually work with the company as well. I am not suggesting that the community develop code to the needs of a company. I am suggesting that perhaps the community needs and the company needs often overlap but both sides tend to ignore the overlap and point at each other instead. --- Company involvement in the community process usually has unforseen benefits, but also unexpected burdens and restrictions. The bottom line is that company and community priorities often diverge. If companies want community feedback, they should plan for such divergence and decide how hard they are willing to work to maintain community cooperation. If a company is not willing to adjust to community needs, often it is wise to avoid the community process. --- O.k. in all Bruce I like your article but I must admit it seems to take a "The community is god" perspective and that we must all bend to the will of said community. The community could learn a great deal from adopting some of the more common business practices when it comes to development as well. In short, I guess I think it is important to recognize that both are partners in the open source world and that to ignore one over the other is destined to fail. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq