LWN.net Weekly Edition for January 21, 2010

LCA: How to destroy your community

Josh Berkus is well known as a PostgreSQL hacker, but, as it happens, he also picked up some valuable experience during his stint at "The Laboratory for the Destruction of Communities," otherwise known as Sun Microsystems. That experience has been distilled into a "patented ten-step method" on how to free a project of unwelcome community involvement. Josh's energetic linux.conf.au presentation on this topic was the first talk in the "business of open source" miniconf; it was well received by an enthusiastic crowd.

If you are a corporate developer, you're likely to realize early on that free software development communities are a pain. They'll mess up your marketing schemes by, for example, taking the software into countries where you have no presence and no plans. They'll interfere with product roadmaps with unexpected innovation, adding features which you had not planned for the next few years - or, worse, features which were planned for a proprietary version. Free software communities are never satisfied; they are always trying to improve things. They tend to redefine partner and customer relationships, confusing your sales people beyond any help. And they bug you all the time: sending email, expecting you to attend conferences, and so on. Fortunately, there are ways to get rid of this community menace. All that's needed are the following ten steps.

#1 is to make the project depend as much as possible on difficult tools. He noted that most companies have no real trouble employing this technique, since it makes good use of the tools they have around anyway. Community-resistant projects should, for example, use weird build systems not found anywhere else. A proprietary version control system is mandatory. Even better are issue trackers with limited numbers of licenses, forcing everybody to use the same account. It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find.

2: Encourage the presence of poisonous people and maximize the damage that they can create. There is a special technique to the management of these people which goes something like this:

1. Take pains to argue with these people at length and to denounce them on the project lists.

2. Eventually, they should be banned from the community by fiat; it's important to avoid any sort of community process here.

3. The banned people will take their flames elsewhere. Follow them and continue to argue with them in those external sites.

4. Eventually the community will complain about this behavior; respond by letting the poisonous people back in. Then go back to step 1 and do it all over again.

Properly managed, one effective poisonous person, according to Josh, can wipe out a community of hundreds.

3: Provide no documentation. There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM.

4: Project decisions should be made in closed-door meetings. An OK start is to have online meetings with very short notice, though, for best effect, they should be at a time which is inconvenient in the time zones where most community members are to be found. Better is to have meetings via conference call: that excludes about a third of the planet due to sleep requirements, and, for extra value, also excludes a number of people who are at work who might have been able to participate in an online meeting. Best, though, is to hold meetings in person at the corporate headquarters.

5: Employ large amounts of legalese. Working with the project should involve complex contributor agreements, web site content licensing, non-disclosure agreements, trademark licenses, and so on. For full effect, these documents should all be changed without notice every couple of months or so.

6: The community liaison must be chosen carefully. The optimal choice is somebody reclusive - somebody who has no friends and really doesn't like people at all. Failing that, go with the busiest person on the staff - somebody with both development and management responsibilities, and who is already working at least 70 hours per week. It's important, in this case, to not remove any of this person's other responsibilities when adding the liaison duty. It can also be effective to go with somebody who is unfamiliar with the technology; get a Java person to be the liaison for a Perl-based project. Or, if all else fails, just leave the position vacant for months at a time.

7: Governance obfuscation. Community-averse corporations, Josh says, should learn from the United Nations and create lengthy, complicated processes. Keep the decision-making powers unclear; this is an effective way to turn contributors into poisonous people. Needless to say, the rules should be difficult or impossible to change.

8: Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything; that will drive away contributors who like the current license without attracting anybody who might like the alleged new license.

9: Do not allow anybody outside the company to have commit access, ever. There should be a rule (undocumented, of course) that only employees can have commit rights. Respond evasively to queries - "legal issues, we're working on it" is a good one. For especially strong effect, pick an employee who writes no code and make them a committer on the project.

10: Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all.

Josh concluded by noting that he saw all of these techniques employed to great effect by Sun. But Sun is far from alone in this regard. Josh has been told by a veteran of the X Consortium that they, too, had made good use of all ten methods at one point or another. Community-destroying skills are widespread in the industry.

But what if you have a different kind of company, one which wants to encourage and build communities? Doing the opposite of all of the above clearly makes a lot of sense. But, Josh said, it all really comes down to trust. A relationship with a development community can be seen like a marriage: one can spend years building it up, but one affair will kill the trust it is based on. Similarly, a company can lose half of its community in a weekend. Those who would avoid that fate must trust their communities and act in a way which will cause that trust to be returned.

Comments (57 posted)

Getting things done in Linux

If your New Year's Resolution includes something along the lines of "be better organized," choosing a task manager might be in order. Linux doesn't lack for task managers, but good ones are few and far between. To help LWN readers boost productivity, we've picked a few to look at.

Tasque

Tasque has the advantage of being very simple. It also has the disadvantage of being very simple. It's a good task system for users who want a fairly quick and easy way to manage tasks without the overhead of a system like Getting Things Done (GTD).

Tasque is a very simple task list that syncs with several backends, or just with a local file. One of the main "selling points" of Tasque, aside from simplicity, is being able to use it with multiple data stores. Tasque works with Remember the Milk, the Evolution Data store, local files, and others.

Task entry and maintenance with Tasque is easy, and it integrates very well with the GNOME desktop. But, Tasque seemed to be a bit laggy when using it in conjunction with the Remember the Milk, though it was very responsive when working with a local data file. Whether the lag was due to RTM or Tasque is unclear. However, over more than a week's time, Tasque was very nearly unusable each time we tried syncing with RTM.

Tasque is shipped by default in openSUSE for GNOME users, and is available for Fedora and in the Ubuntu Universe repository. Source is available via the Tasque pages on the GNOME Web site. It might be a bit too simple for some users, though, which brings us to Tracks.

Tracks: Doing Things Properly

Tracks has the advantage of not only being open source, but also Web-based and available anywhere. Tracks is another tool meant to implement David Allen's Getting Things Done methodology, though it's also suitable for users who don't subscribe to that particular methodology.

Tracks is Rails-based, and not packaged for most major distros. It is available as a BitNami Stack for users who don't have a Web server handy or don't feel like setting up a Rails environment from scratch on their desktop. The BitNami Tracks package features a GUI and command line installer, and requires very little effort.

While Tracks is more heavyweight than Tasque, it's also much more full-featured and capable. Tracks allows users to not only track individual to-dos, but also projects. Since it takes a cue from GTD, it also provides users with a way to track contexts (such as things you do while at the computer, phone calls, errands) and projects via iCal, plain text files, and RSS feeds.

Tracks is sort of multi-user. That is, an instance of Tracks can support multiple users, but each user has her or his own set of actions. It's not suitable for group projects, as there's no way for one user to share projects with another or assign another user actions.

Tracks is ideal for productivity junkies who want to measure progress, or for consultants or employees who want or need to show how they spend their time to clients/employers. Track produces enormous amounts of statistics on completed actions, the number of completed actions in the last 12 months, the days of the week that actions are created and completed, and much more.

Need to get to data via a mobile phone? Tracks also provides a mobile interface via sitename.com/mobile/, without any additional configuration required. Finally, Tracks has an API, so users who have a bit of shell scripting, Ruby, or AppleScript under their belt can get data in and out of tracks using more than the Web interface.

When running under the Bitnami stack on the test machine, Tracks was as snappy as a desktop application — sometimes more-so. The only glitch discovered was that Tracks would throw an Apache error when trying to see recurring tasks. Overall, Tracks seems a very solid application and is quite responsive.

KOrganizer

For KDE users, KOrganizer is the best of the lot. We didn't find any really compelling stand-alone task managers for KDE, but KOrganizer includes a really handy task manager alongside a journaling application and calendar.

KOrganizer is a bit more heavyweight than the others, but very full featured. To-Do entries can have starting dates and times, notes, attachments, send reminders, and attendees. Users who need or want all of that information should definitely explore KOrganizer.

Or it can be much simpler. The stand-alone To-Do list lets users enter task entries as one-liners with no additional information. It's up to the user to choose the level of complexity. Tasks are displayed in the To-Do list view and the calendar view, if the tasks are assigned a completion date.

KOrganizer is very complete for users who are looking for a desktop app without a lot of import/export options. Users who are looking to sync with mobile devices or Web-based services might find KOrganizer a bit limited, but if those aren't on the list of criteria then it's a very handy solution.

Any Linux distro that packages KDE should have KOrganizer in the package repositories, if it's not already installed by default.

Getting Things GNOME

One of the newer task management applications available for Linux is Getting Things GNOME (GTG). As the name suggests, it's a GNOME-based implementation of Getting Things Done.

Despite the low version number, 0.2 was only released in December, GTG is stable and relatively full-featured. Since GTG is new, users will need to either compile from source or look at something like Ubuntu's PPAs or the openSUSE Build Service, where recent releases are available.

Entering tasks is easy, all that's required is a one-liner. Users can opt to tag tasks and add notes, due dates, and so on — but all that's required is a one line entry in the main window. Double click on a task, or click on "New Task" in the GTG main window, and GTG provides a separate window where users can enter additional details about a task.

For management of larger projects, tasks can also have sub-tasks. So if there's a lot of Yak Shaving involved with getting something done, it's possible to track every step of the grooming. This will come in handy for users in a corporate environment.

GTG also supports plugins, and works with several other GNOME productivity tools, including Tomboy and the Hamster Applet for time tracking. At first, it looked like GTG lacked support for a notification icon, which seemed odd — but support for that is also provided through a plugin.

Overall, GTG is a fairly complete solution and should be sufficient for anyone who's looking to implement GTD on a GNOME desktop.

Summary

For lightweight task management, GTG heads the pack. It's light, fast, and provides just enough functionality that users can implement GTD or their own brand of task management. Users looking for a more complete solution will probably find Tracks the most attractive. It's very flexible and provides a very usable interface, despite being a Web-based application.

No matter what the preference, though, it should be able to find a Linux-based task manager to fit the bill. This is one area that FLOSS tools have very well covered.

Comments (19 posted)

Disney and Sony release open source 3-D modeling utilities

Not one, but two, Hollywood movie studios — Disney and Sony Pictures Imageworks — released open source software this past week. The film industry has had a mixed relationship with the free software movement in the past — on the one hand vehemently opposing it on issues like the Digital Millennium Copyright Act, but on the other making heavy use of free software to save money in visual effects render farms. This week's releases are indeed in the visual effects category; tools for 3-D modeling. Disney's project automates texture mapping, and Sony's is a new shading language. Both could benefit the open source community.

Ptex

Disney's Ptex is a library that simplifies the otherwise time-consuming task of mapping the surface of a 3-D model into two dimensions for the purpose of painting it with a "texture," or 2-D image skin. The traditional method unwraps the surface of the model into a flat image template called a UV map (the name refers to the U and V coordinate axes used on the map to distinguish them from the X, Y, and Z coordinate system of the original model). A UV map can be created automatically, but almost always requires manual tweaking by the 3-D artist in order to minimize awkward seams, overlaps, and other artifacts that are difficult to paint. Furthermore, complex models are typically split into multiple texture files, to simplify the resulting maps where the geometry itself is awkward, and to allow for higher resolution textures in important areas.

Ptex speeds up the process in several ways. First, it stores a separate texture for each face of the original 3-D model, eliminating the need for the user to painstakingly unwrap the model and manually adjust the UV map for optimization. Second, it compactly stores all of the per-face textures for the model in a single file, along with adjacency information, thus reducing the I/O load on the animation system. Third, it allows different resolutions for each face, and allows changing face resolutions, both eliminating the need to split a model into multiple textures and allowing the artist to make adjustments directly within the painting application. Finally, it uses the adjacency data to apply filters on the seams between adjoining faces — even those of different resolutions — resulting in a smooth, seamless final texture.

Disney first used Ptex in the 2008 animated short Glago's Guest, and subsequently on "virtually every surface" of the feature-length film Bolt. A presentation available at the Ptex web site describes the time savings for both computing time and artist workflow. Ptex reduced the number of I/O calls to render one model by a factor of 2,000, and cut the number of CPU cycles on another by a factor of 13.

Just as importantly, however, incorporating Ptex into the animation studio's modeling and painting applications speeds up the creative workflow of the team. The need to manually worry about UV mapping every model forced the 3-D modelers to think about how the model would be painted — which should not be their concern — and forced the painters to both learn and, periodically, adjust the UV maps.

The Ptex team has posted a video to YouTube demonstrating how artists interact with a Ptex texture. It is interesting viewing even for those unfamiliar with 3-D modeling and animation; the narrator points out several steps in the process where Ptex allows him to simply paint the model without concern for the underlying geometry while an older system would necessitate stopping or changing the UV map.

The Ptex source code is available under an MIT-style license through Github. The project's web site also includes documentation of the Ptex library API and a file format specification. A 2008 paper is also provided that goes into considerably more detail on the format and filtering. Of note, when the paper was written Ptex only supported one type of 3-D mesh, Catmull-Clark surfaces that use quadrilateral faces. Since then, Ptex has been extended to support additional mesh types, including non-quadrilateral Catmull-Clark meshes and loop subdivision surfaces.

Open Shading Language

Sony's Open Shading Language (OSL) is a language for writing shaders, algorithms used to calculate high-quality simulated lighting effects in the final rendering stage of 3-D animation. Shaders can do everything from model how a surface reflects and scatters light to how light is transformed as it passes through a volume of space (such as fog). High quality shaders can be of arbitrary complexity, thus the necessity of writing them in a programming language.

The most popular shading language is the RenderMan Shading Language (RSL) developed by Pixar. RSL is supported by a wide variety of free and proprietary tools, and several competing languages use the same basic C-like syntax of RSL.

The OSL language specification [PDF] is hosted at Google Code, and is distributed under the BSD license. OSL does away with several distinctions made in RSL and other shading languages, such as treating light sources as a distinct type of shader and transparency as a distinct property. Instead, OSL shaders calculate a "radiance closure," a symbolic representation of how the surface or volume in question affects light. A light source is merely a closure that emits a positive quantity of light, and a semi-transparent material is merely a closure that permits some quantity of light to pass through it.

Closures are also different from RSL-style shaders because, as an abstract representation of a surface or volume's behavior, they can be evaluated from any direction — RSL-style shaders can only be evaluated to a fixed value that represents the final color as calculated for a particular viewing angle. OSL permits closures to be saved for later evaluation and sampled or referenced without re-rendering. An OSL scene can be described as a connected network of closures that are "integrated" as-needed by the renderer. Depending on the viewing angle and lighting for a particular rendered pixel, some closures may not be evaluated at all, and these dependencies are determined automatically.

The practical upshot of OSL is that shader writers can focus more on modeling the physical properties of a surface or volume, and not explicitly concern themselves with implementation details imposed by other, more structured shading languages. The trade-off is that OSL requires significant changes to the renderer to support its significantly different approach. So far, no such renderer is available outside Sony.

The implementation currently available from the project provides a handful of sample OSL shaders, a compiler for translating OSL shaders into an intermediate bytecode form, a library that interprets OSL shaders, and a sample program called testshade that can execute a shader to produce a single test image.

The OSL Introduction page warns visitors about the pre-production state of the code, but notes that Sony has implemented OSL in its production workflow and is beginning to use it for real projects. OSL is currently slower than its other shaders and the team has isolated some missing functionality that needs to be added to the language.

Nevertheless, the OSL team is confident that it will meet its production goals, and promises to roll out updates to the public code in the coming weeks and months. Further out, it is interested in building alternate back-ends that could translate OSL shaders into code executable on GPUs, and experimenting with the LLVM compiler as an alternative to the present bytecode approach.

Open source integration

Considering the freshness of both projects, it is no surprise that neither has a clear future with existing open source 3-D tools like Blender. Both have attracted considerable attention in the community, though, in discussions at sites like Blenderartists.org and BlenderNation. The reaction has been positive, as is usually the case with a new open source utility.

As one might expect, artists who use Blender seem more excited about the prospect of utilizing Ptex, since it frees them from the decidedly un-artistic step of UV-mapping. Less clear is what to make of OSL, which still has a ways to go before it can be evaluated in real-world circumstances. Sony has demonstrated a good track record with its open source projects, however — it released open source tools for database management, voxel storage, and Python string handling in 2009, and has continued to update its code.

Open source developers who only remember the Hollywood movie studios from their legal assaults on DVD decryption and Bittorrent technology would do well to investigate the moves made by the animation studios. However upper management feels, the animators and tool developers there clearly share common ground with the community, and letting that go to waste would certainly be a mistake.

Comments (5 posted)