Artefacts

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 had come up with the phrase, but he had recently realized that many of our best third party ("contributed") Drupal modules are "artefacts of paid work." Unlikely many other types of open source projects where a developer was "scratching 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 instead. Contributing artefacts 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: designs can never be artefacts and training people has no residual artefact.

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 artefact. Design components may be artefacts but there is currently no way to store these artefacts on Drupal.org. Contributed components relevant to Drupal include Lullabot's icons 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 artefact 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, are simply artefacts at the end of the design process. With the artefacts defined we then need to find a way to give as much weight in the Drupal code hosting system to these design artefacts as we give to code artefacts.

The second challenge is that of training. Artefacts of training may be the "learning objects" that we use to train our students--the handouts, the install profiles or the modules we ask them to build. The 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 objects alone 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. Successful training needs to have a curriculum with defined learner roles and tasks and progression. Lots of companies (my own included) train people on how to use Drupal. The training resources that I develop for my students have a very limited shelf life. The pace of change is too quick to recoup development costs between each iteration of the software. In other words: I have no artefacts to share.

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 artefacts of their paid work---they are trying 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 artefacts will they lose students? (Paul reports they have not lost students from posting their read-only course notes.) 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 artefacts of design? Do you see a way to 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?

This piece was originally written for The Open Source Business Resource and was posted there and also over there.

The final link (to "over

The final link (to "over there") doesn't link anywhere.

Link fixed, thanks!

Link fixed, thanks!

"The training resources that

"The training resources that I develop for my students have a very limited shelf life. The pace of change is too quick to recoup development costs between each iteration of the software. In other words: I have no artefacts to share."

Dunno, I would argue the learners are the artifacts. Instead of handouts and files, there's a whole group of people with new knowledge out there to share. If the students then contribute back by teaching others or contributing to the community then the artifacts multiply.

"The risks to sharing for the paid professionals is an interesting challenge that I do not have an answer to."

There is no risk, any more than say a talented musician who posts their composition. It's not the notes on the paper but the artist who can interpret those notes and make something magical happen. In that sense a great teacher is a great artist who adjusts to their audience. The value in training is not in the materials but in the time with the teacher/expert/artist who provides a safe and engaging environment to learn. In technical training learners sometimes need to 'break' things to learn new skills. Doing that at home on one's system with a book or manual or wiki page can be a disaster. In a classroom with a knowledgeable teacher it's a learning moment that keeps them from making the same mistake again.

You are valuable b/c you are a great teacher. You can give away all your materials but unless someone as as equally or more talented than you can take those and give them a better interpretation then your value is assured.

I think the students are the

I think the students are the intended products, not the artefacts!

In training the left over stuff that wasn't the "intended product" is all the material that you needed to help the student learn. I see it as a cascade: the intended product of curriculum development is the training materials and sequence required to help students learn. Once you move into the classroom (be it virtual or face-to-face) your intended product is a student who has achieved (accomplished? can demonstrate?) the desired learning outcomes. What was once the product in the curriculum development phase (i.e. training materials) has become the artefact.

Just like the contributed code is "leftover" after you build and deploy a Web site; the training materials are leftover after you deploy new folks who are all learned up [sic]. With the intended outcome of training being enlightened (ha!) people I don't see how they could ever be lumped in with leftover code.

So, what is it about

So, what is it about ecosystems that makes you think it a reasonable word to tie in with drupal modules. Wouldn't the word 'library', 'collection' or 'mess' be more apt? Body of collective work?

How is it an 'ecosystem of modules' ?!

Here- maybe this will help you: http://en.wikipedia.org/wiki/Ecosystem_ecology

I find the use of the word, here, lazy, ignorant, and unacceptable in 2010.

You're assignment is to read

You're assignment is to read http://en.wikipedia.org/wiki/Metaphor. A 3-page paper is to be handed in no later than Monday.

While technically there is

While technically there is some argument that the correct term should be business ecosystem, the authors meaning and intent came through very clearly, as a means to describe the flow of funding and cascading effects of transactions and development efforts throughout all the members of the Drupal community.

No science education, here,

No science education, here, obviously. Rich in the creative arts.

May your drinking water and energy supplies follow your mental pathways. Dendritic patterns of junk.

Wow... Nasty much? Don't you

Wow... Nasty much? Don't you have anything better to do than troll around hunting for people who don't use the word ecosystem in your approved manner? http://drupal.org/node/394282#comment-3015072

Michelle

Go ahead, keep spreading

Go ahead, keep spreading ignorance.

I must not know anything about metaphor if I call to question the misuse of terminology.
I shouldn't dare follow with any rebuttal to nonsense.

Go ahead, spread the ignorance.

Refer to the collection of modules an 'ecosystem'. It'll make you look real smart!
Let's let it wash into the Drupal vernacular. Ahh.

Hey, and assume I'm trolling because I took the time to respond to something I saw via the Drupal aggregator.

Woo! Yay, us!

It's knitted Drupal. You add

It's knitted Drupal. You add columns and trim the nostrils of the sheep to get your threads. It's just like that! Tight knit, so it falls off your shoulders like a throw.

See?

Don't pester the troll. They

Don't pester the troll. They clearly have more free time than anyone else has patience and are looking to get a rise out of someone. When I have time I'll write a new blog post that answers their original question of how this particular metaphor works and why it applies. I'm sure there are a few people who are having a difficult time understanding the connections.

Git for Teams

Git For Teams

Best selling title from O'Reilly media. Covers essential skills needed to use Git in a team environment.

Available from O'Reilly media, and better bookstores worldwide.

Collaborating with Git

Collaborating with Git

Practical how-to videos to get you, and your team, up and running with Git. A complementary video series for the book, Git for Teams.

Available from O'Reilly media.

Drupal User's Guide

Drupal User's Guide

Site building for Drupal 7. Includes in-depth information on Drupal's most popular site building modules, SEO and accessibility. Two complete case studies are included in the book along with the tools you'll need to build (almost) any Web site with Drupal.

Available from Amazon.com.

Front End Drupal

Front End Drupal

The industry go-to for learning theming in Drupal 6. A great companion to Lullabot's book, Using Drupal.

Available from Amazon.com.