I have the most interesting conversations while at open source conferences. A few weeks ago at CMS Expo I had a great conversation with Jeff Eaton about open source as it relates to things other than code. I'm not sure where Jeff came up with the phrase, but he recently realized that many of the best third party contributed Drupal modules are "artifacts of paid work". Unlike many open source projects where a developer "scratches their own itch", much of the Drupal ecosystem of code has been built by people who were paid for their time.
While this could open up the conversation to all kinds of interesting comparisons and rebuttals and agreements and disagreements, let's head off in a different direction. Contributing artifacts has made the Drupal code ecosystem incredibly healthy and a wonderful place to dive into when you are looking to deploy a Web site with a shoestring budget. There are, however, two main problems that we've not yet solved: i) designs can never be artifacts; and ii) training has no residual artifact.
For the most part, code is generic enough that it can be easily dropped into a new design and re-used without compromising the brand of the original site. This is not true for design. You can't design a new theme for Drupal and then drop it into the community for others to re-use. Design is not an artifact. Design components may be artifacts, but there is currently no way to store these artifacts on Drupal.org. Contributed components relevant to Drupal include Lullabot's icons (Lullacons) and Top Notch Theme's snippet and style repository. The Lullacons can be used outside of the Drupal project, but the theme snippets are only relevant in very specific use cases.
To help designers share their work in the Drupal community, we need to define what an artifact is to a designer. Is it a font? An edge style for a div on a page? Is it a set of icons? What are the abstracted parts of design that, like the contributed code, can simply be artifacts at the end of the design process? With the artifacts defined, we then need to find a way to give as much weight in the Drupal code hosting system to these design artifacts as we give to code artifacts.
The second challenge is that of training. artifacts of training may be the "learning objects" used to train students. Smart (or is that lazy?) trainers will find as many objects as they can from within the free Drupal resources. Teach developers to use api.drupal.org and you have trained them for life. But these objects, or artifacts, do not teach people how to choose a few relevant modules from the thousands that are available. They are about as useful as the .tar.gz file containing a contributed module without the Drupal core code base. To make training work, you need to have a curriculum with defined learner roles and tasks and progression. Many companies (my own included) train people on how to use Drupal. Due to the pace of change in the Internet world, it is unlikely our curriculum will ever become an artifact.
There are projects within the Drupal community that are looking to collaborate on an open curriculum. The Curriculum and Training Group has started meeting weekly on IRC. The Ubuntu project has an equivalent group. But these curriculum projects are not simply releasing artifacts of their paid work---they are trying to generate something for others to use. This changes the dynamic of the participants substantially. For the professionals who train others for a living, what is the incentive to participate? Their own itches are being scratched each time they teach their curriculum. If they release their artifacts, will they lose students? The risks to sharing for the paid professionals is an interesting challenge that I do not have an answer to.
Are you a designer that can list artifacts of design? Help me share the leftovers of your paid work. Are you a paid professional with an open source curriculum, or at least freely licensed curriculum? How did you do it and how has it affected your business?
Posts
No comments:
Post a Comment