The problem I see with selling support is that a well-designed tool shouldn't really require support at all. Ideally the API is clear enough, the documentation well-written enough, and the scope small enough that support isn't required or even worth paying for. But as soon as you monetize support, your incentives aren't nicely aligned with the customers.
The other problem with the support solution is that many programmers dont want to be tech support people, they want to be programmers. you can hire people to do the tech suppprt people, but then you become a business person/manager, rather than a programmer. Even still, building this kind of multiperson business only makes sense for larger projects. I do think it has its place and has prooven successful in some situations but its no silver bullet.
Comments
The problem I see with selling support is that a well-designed tool shouldn't really require support at all. Ideally the API is clear enough, the documentation well-written enough, and the scope small enough that support isn't required or even worth paying for. But as soon as you monetize support, your incentives aren't nicely aligned with the customers.
The other problem with the support solution is that many programmers dont want to be tech support people, they want to be programmers. you can hire people to do the tech suppprt people, but then you become a business person/manager, rather than a programmer. Even still, building this kind of multiperson business only makes sense for larger projects. I do think it has its place and has prooven successful in some situations but its no silver bullet.
Support doesn't mean bug fixing, it may mean things like how do I optimize the software for my particular use case? How can I make it do x?