Really appreciate this article and wanted to add a few of my thoughts. I’ve been an inhouse marketer in the Dev Tool space for 2 different SDK companies over the last 5 years. The majority of my focus has been on paid / organic search channels (primarily google) because these two channels had the largest impact in the number of leads we generate.
The first thing I wanted to touch on is the idea that developers hate marketing - this is 100% accurate and I would recommend anyone doing marketing in the dev tool space to have this mindset.
For me the way I’ve dealt with this concept is to try to reframe what my objective is as a marketer. Fundamentally the SDK’s I’ve worked for do deliver value to a developer by helping them develop tools faster and in a more polished fashion. For some developers this is super useful and for others it will never be an option. For obvious reasons I focus on the developers that would see value in this and do everything in my power to make them aware that our solution exists.
My approach to developer marketing:
- Try to be direct as possible in how I communicate the features / capabilities / benefits while avoiding marketese / jargon etc
- I have a philosophy that if you provide value without any strings you benefit in the long run. That’s why I’ve always opposed gated content or even gating trials if possible.
- Developer experience is fundamental to the success of dev tools business. In my organization marketing takes an active role in dev experience - for example we helped reorganize documentation to make it more accessible and easier to navigate for our users. This had a dramatic impact in product adoption.
- Having a good demo should be the cornerstone of your marketing activities. It’s how developers see what you can do and gives your sales team the tools to sell your product effectively.
- Make use of things like live demos so developers can anonymously learn and observe your team without directly talking to a sales representative.
Some of the things I disagree with in the article.
Google display never works:
- This is not always the case. For obvious reasons retargeting is especially disliked in the developer world but in some cases it works. For me I’ll run a Google display campaign that targets any user that’s downloaded our SDK. For these users I focus on delivery display ads that help them integrate the product more effectively. For example I will create ads for these users that promote free trial support to help them build their POC. Typically marketing is not incentivized to drive an increase in support calls but if a user is having trouble building a POC then this is the ideal candidate for us to send to support.
- This also works for marketing pages - users who land on a marketing page will see ads for ungated content like “Buy vs Build” etc
The missing link between paid and organic traffic
Something that seems to be consistently overlooked is how the effort and money you spend on paid channels should help you make better decisions on increasing organic traffic. This is sometimes the main downside with hiring an agency - they might be really good on managing the paid side but don’t provide input on how you can use this to increase organic channels. For example:
- Identify which paid keywords drive conversions and use this data to prioritize your organic channels.
- Use the number of search impressions for your keywords to accurately measure demand for a service
- Use A/B testing to improve CTR in organic search. For example we had a really good blog article that did not have a great title. I ran a display campaign with different titles for this blog article. After about a month there was a clear winner and we renamed the blog article resulting in the ranking and traffic going up for the article.
Paid search and SEO do increase brand awareness
We primarily focused on paid search and SEO which resulted in a significant increase in the total number of users that searched for a brand year-over-year. The number of people searching for your brand is one of the best ways for you to measure brand awareness.
With all this said I do believe that ultimately any success you have marketing to developers manifests from your intentions. I’ve always believed that my intention as a marketer was to “help developers” by providing them tools to make their lives easier. I think this intention is mirrored in the work I do and has been a part of the reason we’ve been successful.
Thanks for your feedback and your questions Adam! PDF.js Express has been in development since early 2019. We have a number of customers signed up and using it in production, and so far the feedback has been really positive. Your website looks great.
There is no mention of AGPL anywhere in that repository. There is just a LICENSE file with a completely different proprietary license: it is not open source at present. If you intend to make it open source, you need to change the license to an open source one.
Our intention with PDF.js Express is to provide a solution that meets a market need for a PDF.js viewer with out-of-the-box features. Building this viewer that wraps around the PDF.js engine was no small task and we do hope that it will provide some value to developers. With that said, our goal is to grow usage of PDF.js Express and the PDF.js project. Ultimately the more developers we can bring to the platform the better it is for us and for the open-source community. We’ve started by creating articles that should help others get started with vanilla pdf.js: How to Build a PDF.js Viewer in React + Typescript [1] and How to Add Zoom Controls to a PDF.js Viewer [2]. We plan on creating more of these guides and now that we've launched this product, we will be looking to help move the pdf.js project forward.
So you plan to post some advertising tutorials and grow the developer community, aka you're doing nothing, but you're not contributing to the project that is in the core of your product? No wonder open source projects die, no one gives back.
I'm not here to argue, just making an observation.
Thank you for your feedback and question. My apologies if it’s unclear. The source code for the UI is available on GitHub [1], but is minified in the download package for efficiency. Note that even though the code is "open source" in that repo, we still have a custom license [2].
[1] https://github.com/PDFTron/webviewer-ui
[2] https://github.com/PDFTron/webviewer-ui/blob/6.2/LICENSE
The license reads "WebViewer React UI project/codebase or any derived works is only permitted in solutions with an active commercial PDFTron WebViewer license. For exact licensing terms please refer to your commercial WebViewer license. For use in other scenario, please contact sales@pdftron.com".
That is a proprietary source-available license, very much not open source at all.
Please don't use the term open source, not even in quotes, if your code is not available under a license that meets the Open Source Definition or the Free Software Definition.
So which is it? robocop2018 is claiming it's AGPL/commercial dual-licensed, but you say it just has the custom license and that's the only license in the repo?
Thanks for the feedback! We are not part of the core pdf.js team. In regards to pricing we found that for some companies creating their own viewer requires a fair amount of upfront resources - after trying to create their own viewers they realized the time to build and maintain was not economical. The other big consideration is the opportunity cost of sinking developer resources into a viewer that is not a core differentiator.
Right there with you. This is straight up infringement and confusing for everyone involved. This should not be allowed in the slightest. Highly disingenuous for them to do this.
The biggest challenge to pricing based on volume is the exercise of tracking usage. In a typical SAAS product determining usages is fairly linear. For PDF.js Express because you would be deploying from your environment we would not have an accurate way to measure usage. Fundamentally I agree with you - you should pay for what you use. Unfortunately at this time we are not able to implement that effectively. Also keep in mind for some organization the value created from this product will far outweigh the final price tag.
As a startup founder, here are a few alternatives that I would prefer.
1. Community edition - no direct support, maybe some enterprise features no available (like Sencha.com)
2. Hosted version - easier to PAYG with a lower price point per use (like Typekit)
3. One off purchases with updates for just 12 months. Updates then require licensing (like Sketch)
The other option is that you only got for enterprise and exclude the startup and indie developers. Enterprises tend to have no issue doing the right thing. If you're worried about smaller developers taking advantage, then you need to weigh up the long term benefits.
Just remember, if it's hard to do, it doesn't automatically make the wrong choice the right choice.
- One: the model you have right now. this is for organizations where the value outweighs the price tag.
- Two: Smaller organizations are generally also more willing to compromise on JS/asset bundling and performance. Why don't you give them:
- a hosted JS solution where they just have to include a <script /> tag
- An uglified script. I'd argue most JS developers can't unscramble these
- you keep counters on number of requests
- you disqualify (using some basic hashing method) run-ability of PDFJS Express based on the time the script was requested OR if an acknowledgement from a server fails. So say, if someone is using a cached version, the script will either not run at a certain point OR all the documents will be watermarked with "TRIAL".
This second way could also be the best way for getting people started immediately. Include a tag, see a watermark, but you are ready to go.
What about doing something similar to JetBrains, where you offer the product at a significantly discounted rate to startups, rather than based on usage? You would have 1 new customer immediately.
Yes, unfortunately the printing is done with a bitmap because of the lack of browser APIs to print scalable canvas content. It looks like our default print quality is a bit on the low side though, so we'll probably change that. You can use the API to increase the quality as well https://pdfjs.express/api/WebViewerInstance.html#setPrintQua..., for example instance.setPrintQuality(2).
Well, capturing a 72 dpi screenshot and converting to JPEG (which more or less seems to be what you're doing) kind of makes the form filling pointless. Fillable PDF forms exist so they can be printed (or saved and then printed, which I don't think you have an option for either?)
The right way to handle this would be to work with pdf.js, which has been discussing pdf form printing for quite a long time[1],instead of rolling a canvas screenshot hack.
Yes, that's correct. It's not supported by PDF.js [1]. But the good news is that it looks like Adobe is finally moving away from their proprietary XFA format, with the introduction of their forms extension.
The first thing I wanted to touch on is the idea that developers hate marketing - this is 100% accurate and I would recommend anyone doing marketing in the dev tool space to have this mindset.
For me the way I’ve dealt with this concept is to try to reframe what my objective is as a marketer. Fundamentally the SDK’s I’ve worked for do deliver value to a developer by helping them develop tools faster and in a more polished fashion. For some developers this is super useful and for others it will never be an option. For obvious reasons I focus on the developers that would see value in this and do everything in my power to make them aware that our solution exists.
My approach to developer marketing:
- Try to be direct as possible in how I communicate the features / capabilities / benefits while avoiding marketese / jargon etc
- I have a philosophy that if you provide value without any strings you benefit in the long run. That’s why I’ve always opposed gated content or even gating trials if possible.
- Developer experience is fundamental to the success of dev tools business. In my organization marketing takes an active role in dev experience - for example we helped reorganize documentation to make it more accessible and easier to navigate for our users. This had a dramatic impact in product adoption.
- Having a good demo should be the cornerstone of your marketing activities. It’s how developers see what you can do and gives your sales team the tools to sell your product effectively.
- Make use of things like live demos so developers can anonymously learn and observe your team without directly talking to a sales representative.
Some of the things I disagree with in the article.
Google display never works:
- This is not always the case. For obvious reasons retargeting is especially disliked in the developer world but in some cases it works. For me I’ll run a Google display campaign that targets any user that’s downloaded our SDK. For these users I focus on delivery display ads that help them integrate the product more effectively. For example I will create ads for these users that promote free trial support to help them build their POC. Typically marketing is not incentivized to drive an increase in support calls but if a user is having trouble building a POC then this is the ideal candidate for us to send to support.
- This also works for marketing pages - users who land on a marketing page will see ads for ungated content like “Buy vs Build” etc
The missing link between paid and organic traffic
Something that seems to be consistently overlooked is how the effort and money you spend on paid channels should help you make better decisions on increasing organic traffic. This is sometimes the main downside with hiring an agency - they might be really good on managing the paid side but don’t provide input on how you can use this to increase organic channels. For example:
- Identify which paid keywords drive conversions and use this data to prioritize your organic channels.
- Use the number of search impressions for your keywords to accurately measure demand for a service
- Use A/B testing to improve CTR in organic search. For example we had a really good blog article that did not have a great title. I ran a display campaign with different titles for this blog article. After about a month there was a clear winner and we renamed the blog article resulting in the ranking and traffic going up for the article.
Paid search and SEO do increase brand awareness
We primarily focused on paid search and SEO which resulted in a significant increase in the total number of users that searched for a brand year-over-year. The number of people searching for your brand is one of the best ways for you to measure brand awareness.
With all this said I do believe that ultimately any success you have marketing to developers manifests from your intentions. I’ve always believed that my intention as a marketer was to “help developers” by providing them tools to make their lives easier. I think this intention is mirrored in the work I do and has been a part of the reason we’ve been successful.