Wednesday, April 09, 2008
Lock-in
Garrick van Buren's thoughts about how Free & Open Is Its Own Lock-in triggered some of my own thoughts about lock-in that have been going in my head for a while about lock-in.
The simple fact is, we always are locked in to some extent -- we learn a tool set, or a technology, and we want to continue to use it. And we don't want to throw away an investment of years.
I've primarily been developing on the Microsoft platform for most of my post-collegiate career. And we're locked into Microsoft technology all the time -- C#, VB.Net, Microsoft Office, or SQL Server. There are downsides to that, as well as positive sides.
It is tempting to go and say that there would be no lock in if you were in the Linux utopia and then not be sharecropping. And that may be true from a developer perspective -- but the final end user, in most cases, won't be a person with a software development background. And they're really going to be more "locked in" to what their software providers give them in any case.
So unless you're constantly willing to develop and maintain all of the software yourself as an individual --- and very few organizations are willing or able to do that. You're going to outsource pieces of your IT infrastructure. From Operating Systems, to office productivity tools, to database management systems, to enterprise applications like ERP, CRM, Financial Software, or whatever -- organizations are going to have someone else built those pieces. And they should. And as most people aren't devloping software for themselves, but they're devloping it for other people, they're dependent on other people for their work. And you can always have the land whipped out from under you.
It is the investment of energy and effort learning how a tool works, understanding the quirks that any system has -- that's the real lock-in. So perhaps one thing is to focus on the pieces that make something unique -- how can you get to a solution for your unique problem as quickly as possible? It might need to go away eventually -- and so can you built what you need as high on the stack as possible? You want to find ways to be as agile as possible, to use the buzzword in the general sense -- how can you get to a result quickly?
In a related observation, I realized what much of this conversation reminded me of. It's like the work-for-hire debates that I've seen in the comic book industry, especially from people like Dave Sim or the founders of Image Comics. It's perhaps especially relevant as we look at what happens with the the rights related to Superman. I think some of the issues related to lock-in here are similar to the decisions to self-publish or do work-for-hire work in comics. Work-for-hire is really what we're talking about here -- but it is also what most of us are going to end up doing, most of the time, and is frequently what you want to do. To use the comics comparison, if you want to work on an established character, you're not going to have complete control over the situation.
The simple fact is, we always are locked in to some extent -- we learn a tool set, or a technology, and we want to continue to use it. And we don't want to throw away an investment of years.
I've primarily been developing on the Microsoft platform for most of my post-collegiate career. And we're locked into Microsoft technology all the time -- C#, VB.Net, Microsoft Office, or SQL Server. There are downsides to that, as well as positive sides.
It is tempting to go and say that there would be no lock in if you were in the Linux utopia and then not be sharecropping. And that may be true from a developer perspective -- but the final end user, in most cases, won't be a person with a software development background. And they're really going to be more "locked in" to what their software providers give them in any case.
So unless you're constantly willing to develop and maintain all of the software yourself as an individual --- and very few organizations are willing or able to do that. You're going to outsource pieces of your IT infrastructure. From Operating Systems, to office productivity tools, to database management systems, to enterprise applications like ERP, CRM, Financial Software, or whatever -- organizations are going to have someone else built those pieces. And they should. And as most people aren't devloping software for themselves, but they're devloping it for other people, they're dependent on other people for their work. And you can always have the land whipped out from under you.
It is the investment of energy and effort learning how a tool works, understanding the quirks that any system has -- that's the real lock-in. So perhaps one thing is to focus on the pieces that make something unique -- how can you get to a solution for your unique problem as quickly as possible? It might need to go away eventually -- and so can you built what you need as high on the stack as possible? You want to find ways to be as agile as possible, to use the buzzword in the general sense -- how can you get to a result quickly?
In a related observation, I realized what much of this conversation reminded me of. It's like the work-for-hire debates that I've seen in the comic book industry, especially from people like Dave Sim or the founders of Image Comics. It's perhaps especially relevant as we look at what happens with the the rights related to Superman. I think some of the issues related to lock-in here are similar to the decisions to self-publish or do work-for-hire work in comics. Work-for-hire is really what we're talking about here -- but it is also what most of us are going to end up doing, most of the time, and is frequently what you want to do. To use the comics comparison, if you want to work on an established character, you're not going to have complete control over the situation.
Labels: comics, computers, intellectual property, it
Subscribe to Posts [Atom]