I suppose it's hard to sell tools to people whose job it is to build tools, e.g. John Resig could never have sold jQuery because someone would have just written a feature compatible version for free. (edit, well the source is visible so that might be a bad example)
One thing coders do poorly is UX. Most things I’ve seen that are UX heavy done right are commercial and light-years ahead of open-source versions.
Tools are very hard to sell. Especially very specialized tools. And tools for programmers often come with the end-user price of 0, so justifying anything above that is hard.
For me personally, I don't see the need to even use such a tool, let alone paying for it. Many programmers seem to focus on code, but in my experience, that's usually not the problem you have when things go bad.
Software development is the only field I can think of where the making of the tools of the trade is wholly encapsulated by the field itself. Maybe blacksmithing. In such an environment, it makes sense. We make our own tools, and for the most part the most powerful of those tools end up being given away for free. To other people who both use the tools, and have the capacity to improve them. Who then give them away for free.
It is not a coincidence that software development tooling is one of the only fields that has has been thoroughly eaten by open source. It's because the user-developer circle is complete. A mechanical engineer probably doesn't have the skillset to improve the CAD program they're running. A software developer probably has the skillset to improve VIM.
Any tool can crap out code that serves a business need. That's a "product", fine. But it takes someone with a bit finer sense of competence to produce code that can work over a longer term and doesn't drag down the business in years to come.
Because these tools are built with non-programmers in mind. We're not talking about people who are not good at programming. We're talking about people who straight up refuse to read/write even the simplest code, because 1) they're afraid of code 2) they're hired as artists/designers/animators and believe code is never mentioned out of their job description.
Dev tools is one of the hardest segments to tackle.
Developers are notoriously cheap and every one of your developer-customers (falsely) assumes they could build a better version of your product over the weekend.
Developers will always compare your fully-featured, supported product to a shitbag OSS "free" alternative they found on GitHub (abandoned by some dude who tried to build a clone to a real product over the weekend and then discovered that is actually not possible...)
Developers will take great pains to overstate the case for building internal tools as it gives them more control and embededness in an organization.
Selling to developers is not for the faint of heart -- and ironically, takes MORE* sales skill than, say, selling marketing automation tools to marketers. No sales/marketer will say to you on a sales call:
"You know, I could build that if I wanted to...."
First-time entrepreneurs who happen to be developers often attack devtools because that is all they know.
Programmers spend an inordinate amount of time thinking about languages and tools, but don't want to pay for better ones, even when they are extremely cheap, drastically increase their productivity and save many headaches. Every other week, there is a post on HN complaining about funding open source. One of the few languages offering halfway decent tooling support is bad because... it makes users more dependent on tools? This makes no sense. Same story for Wolfram. If you want nice things, pay for them.
> First you claimed that having a toolset built using familiar technologies was useful to nobody (0% of developers!)
That's not exactly what I wrote.
> Then you declared that this is useless because no developers actually work on the products they will use for development. I responded by giving your examples where this happens.
Wrong again. A very small subset of developers actually build their own times. Writing a Gulp configuration is not an example of building your own tool. That would be an example of using a tool, and writing your own configuration for that tool.
This is the core of my argument. If you can't grasp this, then we can't get anywhere.
> Now, you are claiming that those tools are pointless because they use libraries in other languages or because there are alternatives in other languages.
That isn't what I am claiming. I am claiming that most web developers do not build their own tools. Writing some glue code (shell script, Makefile, Gulpfile, whatever), which calls out to another tool (like the aforementioned tools written in C), is not an example of writing your own tool.
Do you care what language your linter is written in? No. You do not. You only care about its API. You only care that it's easy enough to use from JavaScript. If you can write `gulp do-the-linting`, and it lints your JavaScript, you don't actually care what language the linting engine was implemented in. Almost — again almost — 0% of web developers care about that.
It's like the equivalent of judging a carpenter for using power tools because he's just not dedicated and gritty enough to use a manual twist drill.
My anecdata, people who overly focus on language and tools tend to be the worse developers. It's the developers that effectively address the universal problems of writing software people want to use, like api usability, reliability, data consistency, maintainability that have the most props in my book.
I don't think my observations relate to sales and marketing. They are more a matter of engineering...intended use, documentation, process. Engineers will use Bash and Vim and Chrome developer tools whether or not they have trendy UI's and are backed by marketing campaigns. They use them because they make them productive and or profitable.
Or to put it another way, if you're not good at lying or telling half truths or spinning bad news, then just tell the truth as best you can. Developer tools are mostly about the tool and only sometimes eventually about the marketing and sales.
The challenge is that when you're building software for developers, they already know how it must work.
Do you mean that what you built didn't worked as it should? I don't understand, I've paid multiple times for tools that I find useful, even if they weren't perfect.
This misconception has been promoted by companies with an interest in promoting their platforms, using the expeditive procedure of subsidizing (often inferior) tools, with the collateral effect of making impossible for tools vendors to compete.
But by no means it's a law of physics. Make something programmers want. It's weird how little have the tools improved in twenty years.
The stuff that programmers are interested in usually have 10000 tools made already but if you look at other industries or hobbies there are a lot of people using crappy expensive tools. A few times I have found areas where no tool exists like a few months ago I needed a ruby library that could download a picture from stitched together OSM tiles and nothing did that.
You can pretty easily find an area where you can easily be the only/best open source tool for the job and there are a lot of people who will use your tool just because it's open source.
I disagree with that. We got really good tools today but writing software is still quite hard, not because of the imperfections of our tools but because the essence of software development is hard. If you're not good (yet) at coding, chances are that you will run into an insurmountable problem before you can release an initial version, unless your web app is doing something really trivial, in the technical sense.
I've heard it differently, but is a corollary: bad tools make it easy for bad developers to do bad things. Good tools make it easy for bad developers to do good things.
One thing coders do poorly is UX. Most things I’ve seen that are UX heavy done right are commercial and light-years ahead of open-source versions.
reply