Consider that your Transforms should be useful to a large audience. In other words - if your Transforms perform a reverse phone book lookup for the 20 people of Timbuktu it is likely not very useful for the rest of the world. If the same Transform runs a lookup for everyone in the UK this is useful.
Test your Transforms
Nobody likes to play with Transforms that don't work. If your Transforms are not tested properly, don't submit them. Rather test it a little more and then submit. If people start complaining that your Transforms are not working we're going to remove them (after discussing it with you of course).
If your Transforms break or do not function as expected, or the user is using it incorrectly then please ensure that your Transforms return meaningful feedback to the user. Don't assume users will simply know what to do. Please also set the verbosity of the error message to an acceptable level. Nobody wants to see fatal messages that result in a recurring pop-up.
Document your Transforms
Remember that your Transforms are now in front of everyone with a Maltego client. You might have tested it with a group of 10 friends that know how they work, but don't assume that everyone will figure it out. Document how to use it, preferably with a case study and a walk-through. Or a video.
Please use the URLs and descriptions in the Transform Hub. Make sure the links work and that the content on the pages are relevant.
If your Transform is using API keys and/or credentials ensure that it's easy for users to register and that the registration process works well. We prefer that you use the fields provided in the Transform Hub specifications and map these to Transform settings.
Working Transforms out-the-box
If your Transforms require an API key or registration please ensure that you state that clearly in the meta data. When the key credentials are not present or are wrong please return a 600 error - this will tell the client to ask the user to supply a new or valid key/credentials. Users will install the Transforms and if they don't work out the box you'll have confused users.
Where possible, use the Standard Maltego Entities. This would mean that users can run other Transforms on your results. Avoid 'dead-end' Entities - these are Entities which no Transforms are able to run on - these tend to become leaf nodes. Furthermore, when extending the Entity's definition, try to re-use fields if they already exist, and when they don't, make sure that they are defined in the Entity's definition and are not dynamically added by the Transform. This allows users to start with a fully capable entity. If you don't understand what this means you need to either contact us, or think about it a little more. Data modelling is the most important part of writing Maltego transforms. Plan it carefully and it will save you a lot of time in the long run. Make use of transform settings and entity properties - it's there for a reason! Also refer to the list of standard entities and their properties/fields before you start!
Transform Naming Conventions
Name your Transforms similarly. In the context menu, Transforms are sorted by Transform name. As such it makes sense to start your Transforms all with the same two or three letters. E.g. FTfirst and FTsecond. Do not name your Transforms too generically – e.g. Maltego1 or Maltego2. Remember that your Transforms are not the only Transforms in the Hub.
Free Release or Initial Evaluation Period
The Transform Hub will only really work if users can explore your Transforms for free (at first, or at least with a trial).
Entity Naming Conventions
Group your Entities in one group and name them something closely connected to your project name. Having 3 groups with 2 Entities in each is no fun. Yes...we know we do it but then again, we've been at it for many years. Because Maltego currently does not delete Entities upon uninstall (there good reasons for this - think shared Entities) you should make it easy for the user to see which Entities are connected to your project.