As can be seen from the GitHub contribution chart, I’ve been doing the vast majority of the development and maintenance on FollowTheMoney (as part of my work on OpenSanctions) anyway.
Word on the street is that OCCRP already has a name for its fork of followthemoney. I would like to avoid a pdfminer-like mess to form here, name-wise.
In practical terms, this would mean:
Moving (or forking) the GitHub repository to opensanctions
Publishing the JavaScript/TypeScript bindings as @opensanctions/followthemoney instead of @alephdata/followthemoney
Including the library in our GH Enterprise security scanning perimeter.
Last weekend, @tillprochaska, @simon and I had a really productive meeting in Berlin to discuss the development agenda for FtM 4.0. We’re very aligned on the objectives, which include:
Cleaning up some of the type/name collisions as described here.
Removing some deprecated properties and the Post schema, following an examination of OCCRPs exposure
Introducing a more tight definition of the number property type
Support for units on numeric properties
Moving the .caption() method from PropertyType to Property to allow considering format/unit
Bringing the data catalog and statements functionality from nomenklatura upstream into FtM
Beyond 4.0, I’d look to consider (!) a few long-term changes:
Moving the documentation to mkdocs to reduce maintenance burden (sorry, Till..)
Inlining rigour into followthemoney as followthemoney.core
Bringing a generic graph backend store spec into followthemoney
Replacing the Neo4J graph exporter with a more configurable version, and making it compatible with the Memgraph database.
What we’re not going to do is make FtM incompatible with Aleph or OpenAleph. That means we’ll retain the schemata used by Aleph and not OpenSanctions, and we’ll keep working with the Aleph maintainers to make sure the development benefits everyone.
FollowTheMoney is a great asset to the anti-corruption open source tech community. We commit to giving it an excellent home, and allocate extensive development resources to it’s evolution and maturation.
I’m a bit disappointed to see a lack of engagement on this, in particular by OCCRP management. In order to make sure that our core framework doesn’t disappear without fair warning, I’ve taken a minimum set of actions needed to give us that certainty.
I would still love to see a more constructive discussion on how we can ensure that both open source Aleph/FtM, and OCCRP Alfred will come out of this transition as stronger software ecosystems.
OCCRP management here. As you are aware, we had to significantly downsize due to the ongoing attacks against OCCRP and a large amount of frozen/canceled funding. I’m sure you know we’re doing our best on our end but we can’t always be as speedy as we want to be, and we appreciate your patience at a somewhat difficult time!
We’re actually investing heavily this year into scoping and building the next version of FtM, which will remain very largely backwards compatible with the current version but will introduce some really key improvements (which I suspect you may already have heard about ). We’re not quite ready to publish changes yet but we would love to talk further about what we’re doing and get your input on some of the decision making, to ensure it aligns as far as possible with OpenSanctions. OCCRP is committed to continuing to develop FtM for the foreseeable future, as we know how core it is to your activities and those of the other organizations you mentioned.
Additionally, we’re committed to keeping FtM – and the new version of it – Open Source and to continue to encourage active collaboration on it from the community – including OpenSanctions – and we’d be really happy to discuss with you further what we’re doing and get your input on some of the technical decision making, to ensure it aligns as far as possible with OpenSanctions, OpenAleph as well as OCCRP’s new generation of tooling including Aleph Pro. Let us know and we can set something up to discuss requirements and approaches.
-E
PS. Our new version of Aleph is called Aleph Pro, not OCCRP Alfred
I guess everyone at DARC is open to being part of that conversation, of course. But it’s really hard to rely on something that we have no say/insight in while it’s being developed behind closed doors and that is going to be largely backwards compatible. To me, it would be a natural move for OpenSanctions to take over.
Hi @ezana.ceman - thanks for your response. Given that OpenSanctions employs eight people based on a product that is wholly dependent on FtM, and given that I’ve been contributing the majority of FollowTheMoney code in the last four years, I don’t feel it’s inappropriate for me to ask for some clarifications following the announcement of Aleph Pro.
The announcement marks a partial departure from the open-source model of development, and the community built around it. OpenSanctions, effectively a for-profit partner in this development, shares part of the codebase and its development cost. Consequently, I speak as the product owner of OpenSanctions when I ask for clarity on what lies ahead.
I worry that OCCRPs lack of transparency will force a growing fragmentation of this open source project. This leads OCCRP into realizing a large net loss in efficiencies and cooperation, long before the organization has proven to itself that it can make a single cent from the new products it intends to market. As an outsider I’d encourage you to assess if OCCRPs commercial aspirations actually necessitate that course of action. There’s no money in burning down your own village.
I appreciate that it is difficult for you - and OCCRP - to give good answers to all of this. What I’m trying to say is: you don’t actually have to give all the answers. This is not a producer-consumer relationship. We can still work out some of the answers together. All I’m asking for is that you don’t leave scorched earth on your way.
Are the changes that I’ve proposed for FtM 4.0 compatible with the future version of FtM that the OCCRP is working on actively?
Will there be an opportunity to reconcile the two branches of development and make sure they’re compatible? How will that process look?
Once the new, open-source version of FtM is released, will it be managed as a collaborative open source project? What kind of governance do you imagine?
If OCCRP-FtM is open-source but the platform on top is closed-source, where is the boundary? Is the closed-source platform actually using OCCRP-FtM? How will future development be coordinated between the two zones?
). We’re not quite ready to publish changes yet but we would love to talk further about what we’re doing and get your input on some of the decision making, to ensure it aligns as far as possible with OpenSanctions. OCCRP is committed to continuing to develop FtM for the foreseeable future, as we know how core it is to your activities and those of the other organizations you mentioned.