10 very simple tips for OSINT tool developers

cyb_detective
OSINT Ambition
Published in
8 min readJan 13, 2023

There are 4,329 repositories on Github using the keyword OSINT.

Github search “osint”

Only 1,162 (26.84%) of them have more than 5 stars.

Github search “osint stars:>5”

That is, only a quarter of the #osint tools and learning materials are noticed by anyone other than the creator and his close friends.

And only 378 (8.7%) of them have more than 100 stars.

Github search “osint stars:>100”

Yes, only one in ten projects on Github marked with the OSINT tag is positively evaluated by at least a hundred people.

Only 78 (1.8%) have more than 1000 stars.

Github search “osint stars:>1000”

Slightly more than one per cent of projects manage to gather a meaningful number of followers.

And these are normal statistics for Github for repositories on almost all topics. The vast majority of open source projects never find an audience.

Twitter cyb_detective

I’ve had a Twitter account for almost two years now. In it I talk daily about different tools and learning materials that I think might be useful to those involved in OSINT.

All the tools I talk about are completely free, partially free or offer a free trial version. And about 60-70% of them are open source and available on Github.

For almost two years now, I’ve been regularly browsing the GitHub for new tools and adding new features to old ones.

And most of the repositories I’ve looked at don’t make it into the tweets. The main reasons are very poor documentation (or more often lack of it) or the tool not working (or more often just incomplete)

Readers also regularly write to me asking about the tools from the tweets and complaining about problems they are having.

During two years, I have accumulated enough observations about what things helps to promote open source osint tools and what hinders them. Often the reason projects fail is that their creators neglect very simple, quick and free actions.

Here are 10 tips to help you increase the chances of your open source osint tool finding hundreds (maybe thousands) of loyal users.

№1 Set yourself up for long-term work

Last year activity of mxrch (developer of Ghunt)

If you are going to put a tool on Github, the first thing you should do is grab your smartphone and set yourself a weekly reminder to “go to Github, read user requests, at least improve the tool’s code a bit”.

The vast majority of developers abandon their pet-projects after a few days, or at best a few weeks. If you can devote regular attention to your project for at least a couple of years, it will surely be in the top 5% in its field.

№2 Start with README.md

https://github.com/sherlock-project/sherlock

Before you start put your code on Github, write a detailed description of how to work with your tool. Ideally this should include:

  • the installation process from scratch. For example: open a command line, check if you have Git installed, check what version of Python you have etc + links to detailed installation instructions for each application you need to run your tool;
  • a description of each command with examples (which work and produce results) for each option (flag);
  • headings, lists, highlighted code blocks, and other design elements that make the text more readable;
  • lots of screenshots and gifs, which show how the tool works.

I am always amazed how many creators of good and working tools do not write a Readme at all.

№3 Make tool installation as easy as possible

https://github.com/soxoj/maigret

Ideally, it can simply be installed with a single command from the package manager (“pip install yourtool” or “npm install yourtool”).

How to Upload Your Python Package to PyPI

NPM Docs. Creating and publishing scoped public packages

If you want to add something extra to the scheme (such as Docker or pyenv), consider doing away with it or doing two installation methods — simplified (with a smaller feature set) and advanced.

№4 Make first launch as easy as possible

It would be great if the tool could be run immediately with one command and one argument after installation.

If API keys are needed to run the tool, ask the user to enter them when first starting. Don’t ask the person to open the files and write the API keys there manually (some users may be put off by this, I’m serious).

№5 Make online launching possible

https://github.com/soxoj/maigret

Although there are lots of in-depth instructions on how to run Python tools at the command line, I regularly get messages from people asking how to run Python tools at the command line (and more often than not they need help already at the step).

Therefore, it would be great to make links to the online launch of the tool. This can be arranged with the help of sites such as Google Cloud Shell, Replit, Colab, Launch binder, Gitpod etc.

№6 Test your tool on different operating systems

https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

If you suddenly failed to make links to the online launch of your tool (for example, Gitpod restricts some features of tools and can block an account for using Tor), try to carefully check how your product runs on Windows, MacOS and Linux (at least check the installation on Kali and Ubuntu).

This can be done with free virtual machines, which are installed in a few minutes.

Linux — http://osboxes.org

Windows (legal, free 90 days) — https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/

MacOS — https://developer.apple.com/documentation/virtualization/installing_macos_on_a_virtual_machine

№7 Don’t forget the help command

https://github.com/sherlock-project/sherlock

A very simple thing that a lot of developers forget about.

№8 Add a bit of personality

https://github.com/dievus/Oh365UserFinder

Display a large, brightly colored caption with the tool name when you execute commands. You can add your nickname and contact information to it. The name should be not too long, memorable, and reflective of the tool’s functionality.

№9 Use automated tools to assess the quality of your code

https://github.com/cipher387/code-understanding-tools

When posting code on Github, try to meet at least one main requirement — “the code must be at least somewhat understandable to other people”.

To do this, you need to name the variables expressively, write comments, and try to follow other standard rules.

You can check the quality of your code with a lot of free online tools.

https://github.com/cipher387/code-understanding-tools

And after each edit, you can format the code with free beatifiers.

№10 Promote your tool outside of Github

To attract the very first users, you need to place a link to your project at least 5–10 sources. This will allow you to get the first feedback and activate the “word of mouth”.

Here are a few examples of what can be done.

Posts in special subreddits:

reddit.com/r/OSINT/

https://reddit.com/r/GEOINT/

https://reddit.com/r/SOCMINT/

Post on HackerNews:

https://news.ycombinator.com

Create page on ProductHunt:

http://producthunt.com

Write a tweet with the tag #osint and tag popular Osint tool reviewers on it to get their attention:

And, of course, you should not be lazy to post links to your tool in any of your accounts on social networks, where there is at least some audience interested in technology.

What was the purpose of creating open source osint tools?

This article is intended for those who are already making an open source osint tool, or are determined to make one.

If you are not one of them, but already started thinking about doing it too, I advise not to hurry to make a decision.

First, keep in mind that developing open source tools is an activity that is extremely difficult to monetize. If you look at the profiles of independent developers on sites like Buy Me a Coffee, you can see that they very rarely get donations for their work. Even with thousands of stars, a tool may only have a few dollars in donations.

If you want fame, it’s much easier to get a TikTok account. But still, the creators of osint tools are welcome guests at various IS conferences, they are sometimes offered to write guest articles in popular IT-media, sometimes users write to them with gratitude, and sometimes their tools are noticed by employers. It would be more exact to say that developing your own tools is a possible way to gain useful connections. But there is no guarantee that your tool will become popular enough to do so.

You could say that developing your own tools is first and foremost a rewarding experience. But it will but definitely useful to you only if you are going to work alone or in small teams all your life. If you are a young programmer and are going to make a corporate career, you are better off spending your time to get a student internship at a large company.

The only reason to make open source osint tools is the desire to be useful to people without getting anything in return.

Many thanks to all the hundreds of members of the osint-community who regularly and unselfishly work on their projects.

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Published in OSINT Ambition

Improve your OSINT and investigations skills with us. We share expert tips, tools, latest trends and insights on OSINT. Subscribe to our weekly newsletter for receiving all OSINT updates in your inbox at newsletter.osintambition.org

Written by cyb_detective

I write about #osint (open source intelligence) tools and techniques cybdetective.com

Responses (1)

What are your thoughts?

All your points are spot on. I have an open source project that has almost has +170K installs. To this day, I haven't received any compensation, knowing full well that businesses use my tool for commercial applications. Though, I stand by everyone's…

--

Recommended from Medium

Lists

See more recommendations