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:
- Take pains to argue with these people at length and to
denounce them on the project lists.
- Eventually, they should be banned from the community by fiat; it's
important to avoid any sort of community process here.
- The banned people will take their flames elsewhere. Follow them and
continue to argue with them in those external sites.
- 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
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
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 (56 posted)
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 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.
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.
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)
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.
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.
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
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)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: BackTrack 4: the security professional's toolbox; New vulnerabilities in bind, glibc, gzip, kernel,...
- Kernel: LCA: Why filesystems are hard; Uprobes: not quite there yet; Secrets of the Ftrace function tracer
- Distributions: LCA: Cooperative management of package copyright and licensing data; new releases of AV Linux, openSUSE Build Service, Open Xange, Pardus Linux, Puredyne, and Ubuntu 'Lucid'.
- Development: 0MQ: A new approach to messaging, Android development overview, Camp KDE report, new versions of mpd, Samba, moin, Tinyproxy, CoffeeSaint, SystemTap, Audacity, GNOME, SQL-Ledger, MusE, Qtractor, Perl, py.test, LDTP, monotone.
- Announcements: EFF petitions FCC on net neutrality, Ted Ts'o changes jobs, linux.conf.au live feeds, AthCon cfp, Power Management cfp, Collaboration Summit cfp, Linux Foundation 2010 Events, Debian Developer Japan/BSP conf, OOoCon 2011 call for location, Linux.com job board.