I want to put together a series of posts about cyborg perspectives on industrial IT practices. This post introduces that series.

The "cyborg analysis," makes difficult to ignore that most problems with technology, even seemingly outright "technological problems" are better as understood as problems at the intersection of humans and technology. Ignoring either people or technology, leads to imperfect analysis. While, false divides between "problems with users," and "problems with technology" aren't helpful either, this might be a conceptually useful exercise.

I've been thinking that many of the seemingly technological problems of IT policy are really not technological problems at all, and are better thought of as "people problems." I'm thinking of "problems" like file permissions, access control, group and user management, desktop management, and data organization. Obviously, some problems, like workflow and tool optimization, are seen human problems while others are often targeted as technological problems.

I think of human solutions as those responses to technology issues that address misunderstanding by providing training and education to users. There's also a class of automations that make these human solutions easier to provide: for example, test harnesses of various sorts, code/text validation, and some template systems. Technological solutions, by contrast are those that, through the use of code, enforce best practices and business objectives: web filters, access management systems, and anything that are designed to "break" if business policy are not satisfied.

The divides between solutions are not natural or clear, just as problem domains in IT are rarely neatly or easily "silo'd." There is often a fine line between writing code to automate a process to make users' work easier and writing code to control users and save users from themselves.

This post, and the series that follows it, are thus to explore this tension, and what I suspect are under-realized opportunities for human-solutions. I would like to think that problem domains in the larger IT world, particularly with thorny issues that require lots of code, may be better addressed with more human-centric solutions. Current thoughts revolve around:

• The practice and method of software design.
• The development and use of software developed for "internal use," rather than as a software product.
• Refraining the discussion about digital security to address it from a human angle rather than from a purely technological angle.

As always, I'd like to invite comments and discussion.

Just about everyone keeps a task list of some sort, or has at some point. To the casual observer, task list management might seems like a simple problem that could be augmented with a little bit of automation for great effect. Fire up your nearest "app store" and I would bet money that you'll find a at least a few developers that have had the same thought.

For such a seemingly simple engineering problem there is an inordinate amount of really bad software. While this might tempt us to reassess the complexity of the task management problem, I don't think this is really true. What happens, I'm convinced, is that people (i.e. cyborgs) make lists of tasks to solve different problems in their realities, and these different lists often require different automation. So while there are 10-20 basic task management applications, the number of distinct usage profiles exceeds that by several times. That's the theory at any rate.

I've been milling over this post about big data in the IT world for quite a while. It basically says that given large (and growing) data sets, companies that didn't previously need data researchers suddenly need people to help them use "big data." Everyone company is a data company. In effect we have an ironic counter example to the effect of automation on the need for labor.

These would be "data managers" have their work cut out for them. Data has value, sure, but unlike software which has value as long as someone knows how to use it, [1] poorly utilized data is just as good as no data. Data researchers need to be able to talk to developers and help figure out what data is worth collecting and what data isn't. Organizations need someone to determine what data has real value, if only to solve a storage-related problem. Perhaps more importantly data managers would need to guide data usage both technically (in terms of algorithms, and software design) and in terms of being able to understand the abilities and shortfalls of data sets.

There's a long history of IT specialist positions: database developers, systems administrators, quality assurance engineers, release engineering, and software testing. Typically we divide this between developers and operations folks, but even the development/operations division is something of a misnomer. There are merits to generalism and specialization, but as projects grow, specialization makes sense and data may just be another specialty in a long tradition of software development and IT organization.

Speicailization also makes a lot of sense in the context of data, where having a lot of unusable data adds no value and can potentially subtract value from an organization.

Most of the sites I visit these days are: Wikipedia, Facebook, sites written by people I've known online since the late 1990s, people who I met online around 2004, and a few sites that I've learned about through real life connections, open source, and science fiction writing. That's about it, it sounds like a lot, and it is, but the collection is pretty static.

As I was writing about my nascent list of technical writing links, I realized that while I've been harping on the idea of manually curated links and digital resources for for a single archives for a couple of years now, I've not really thought about the use or merits of manually curated links to the internet writ large.

After all you can find anything you need with Google. Right?

I mostly assumed that if I could get people to curate their own content, "browsing" would become more effective, and maybe Google technology could adapt to the evolving social practice?

Though the inner workings of Google are opaque, we know that Google understands the Web by following and indexing the links that we create between pages. If we don't link, Google doesn't learn. Worse, if we let software create all the links between pages, then Google starts to break.

Put another way: the real intelligence of Google's index isn't the speed and optimization of a huge amount of data--that's a cumbersome engineering problem--but rather our intelligence derived from the links we make. As our linking patterns change, as all roads begin to lead back to Wikipedia, as everyone tries to "game" Google (at least a little) the pages that inevitably float to the top are pages that are built to be indexed the best.

And Google becomes a self-fulfilling prophecy because whatever page we do find out about and create links to are the links that we've found using Google. We've spent a lot time thinking about what happens if google becomes evil, to think about what happens to us as Google stops providing new and useful information. We've spent considerably less work considering what happens when Google becomes useless.

Security, of technological resources, isn't a technological problem. The security of technological resources and information is a problem with people.

There.

That's not a very ground breaking conclusion, but I think that the effects of what this might mean for people doing security [1] may be more startling.

Beyond a basic standard of "writing and using quality software" and following sane administration practices, the way to resolve security issues is to fix the way people use and understand the implications of their use.

There are tools that help control user behavior to greater or lesser degrees. Things like permissions control, management, auditing, and encryption, but they're just tools: they don't solve the human problems and the policy/practice issues that are the core of best security practice. Teaching people how their technology works, what's possible and what's not possible, and finally how to control their own data and resources is the key to increasing and providing security services to everyone.

I think of this as the "free software solution," because it draws on the strengths and methods of free software to shape and enhance people's user experience and to improve the possible security of the public network as a whole. One of the things that has always drawn me to free software, and one of its least understood properties, deals with the power of source code to create an environment that facilitates education and inquiry. People who regularly use free software, I'd bet, have a better understanding of how technology works than people who don't, and it's not because free software users have to deal with less polished software (not terribly true), but has something to do with a different relationship between creators and users of software. I think it would be interesting to take this model and apply it to the "security problem."

With luck, teaching more people to think about security processes will mean that users will generally understand:

• how encryption works, and be more amenable to managing their own cryptography identities and infrastructure. (PGP and SSH)
• how networking works on a basic level to be able to configure, set, and review network security. (LAN Administration, NetFilter)
• how passwords are stored and used, and what makes strong passwords that are easy to remember and difficult to break.
• how to control and consolidate identity systems to minimize social engineering vulnerabilities. (OpenID, OAuth, etc.)

There's a lot of pretty basic knowledge that I think most people don't have. At the same time, I think it's safe to say that most of the difficult engineering questions have been solved regarding security, there's a bunch of tooling and infrastructure on the part of various services that would make better security practices easier to maintain (i.e. better PGP support in mail clients). In the mean time....

Stay smart.

[1]	Security, being a process, rather than a product. Cite.

"Do eye glasses make us all cyborgs?" Someone asked me a few days ago.

I was annoyed more than anything.

Of course they do. Corrective lenses are a non-biological technology that shape our experience of the world and of our bodies. By this logic, pretty much every tool developed as a product of "technology" (applied science; otherwise known as tinkering with stuff,) renders us cyborgs.

I like the notion that cyborgism is the rule and not the exception in the course of human history, but it makes the conversation about the cyborg moment more banal. A more banal cyborg moment makes it harder to think about the parts that I think are most interesting: the internet, distributed collaboration, free software and open source, and the impact of technology on literature and reading/writing.

As a retort, I said something like, "Perhaps, but if you accept that eye glasses create cyborg beings, then you'd have to accept that shoes also create cyborgs. And the effects of shoes are much more interesting."

Shoes affect how far people can walk, the speed of independent locomotion, they prevent all sorts of awful injuries, and probably lengthen the lifespan as a result. Shoes probably also change our feet and make us dependent upon wearing shoes, and more prone to certain kinds of injuries when barefoot. Fascinating stuff.

All other things being equal, I'm going to stick to internet and the cyborgs resulting from the encounter of humans and that technology.

By eliminating the artificial scarcity of software, open source software forces businesses and technology developers to think differently about their business models. There are a few ways that people have traditionally built businesses around open free and open source software. There are pros and cons to every business model, but to review the basic ideas are:

• Using open source software as a core and building a thin layer of proprietary technology on top of the open source core. Sometimes this works well enough (e.g. SugarCRM, OS X,) and sometimes this doesn't seem to work as well (e.g. MySQL, etc.)
• Selling services around open source software. This includes support contracts, training services, and infrastructure provisioning. Enterprises and other organizations and projects need expertise to make technology work, and the fact that open source doesn't bundle licensing fees with support contracts doesn't make the support (and other services) less useful or needed for open source.
• Custom development services. Often open source projects provide a pretty framework for a technology, but require some level of customization to fit the needs and requirements of the "business case." The work can be a bit uneven, as with all consulting, but the need a service are both quit real. While the custom code may end up back in the upstream, sometimes this doesn't quite happen for a number of reasons. Custom development obviously overlaps with service and thin-proprietarization, but is distinct: it's not a it doesn't revolve around selling proprietary software, and it doesn't involve user support or systems administration. These distinctions can get blurry in some cases.

In truth, when you consider how proprietary software actually convey value, it's really the same basic idea as the three models above. There's just this minor mystification around software licenses, but other than that, the business of selling software and services around software doesn't vary that much.

James Governor of Red Monk suggests a fourth option: Packaging technology.

The packaging model is likely just an extension of the "services" model, but it draws attention to the ways that companies can create real value not just by providing services and not just by providing a layer of customization, but by spending time attending to the whole experience, rather than the base technology. It also draws some attention to the notion that reputation matters.

I suppose it makes sense: when businesses (and end users) pay for proprietary software, while the exchange is nominally "money" for "license" usage rights, in reality there are services and other sources of value. Thus it is incumbent upon open source developers and users to find all of the real sources of value that can be conveyed in the exchange of money for software, and find ways to support themselves and the software. How hard can it be?