Consider that your transforms should be useful to a large audience. In other words - if your transforms do a reverse phone book lookup for the 20 people of Timbuktu it is probably not that useful for the rest of the world. If it's everyone in the UK - different story.
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 speaking to you of course). Broken transforms make you look bad, and by association, make us/Maltego look bad.
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 they'll know what to do. Also – please set the verbosity of the error message to an acceptable level. Nobody wants to see fatal messages that result in a pop-up all the time.
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 specification 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 wrong please return a 600 error - this will tell the client to ask the user to supply a new or valid key/credentials. People will install the transforms and if they don't work out the box you'll have confused users. Confused users are normally angry users.
Where possible use the standard Maltego entities. This would mean that user can run other transforms on your results. Avoid 'dead-end' entities - these are entities where no transforms can run on - they 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 Convention
Name your transform 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. FTblah and FTmoo for the Forensics Tool blah and moo transforms. Do not name your transforms too generic – e.g. MaltegoMoo or MaltegoBlah. That’s just silly. Your transforms are not the only transforms!
Make it free or at least have an eval
The transform hub will only really work if users can explore your transforms for free (or at least with a trial). Making everything paid for is the quickest way the transform hub will die.
Entity Naming Convention.
Group your entities in one group and call it something that is 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.