by Jack Condon
Years ago, visionaries gathered to bring form to something largely ungoverned. They knew in order to create a lasting system, their creation would have to be well thought-out, for certain, but also flexible, so it could adapt to changing needs and attitudes. We may be talking about the founding of the United States and drafting of its Constitution – or we may be talking about the creation of AFP.
“The wise man is one who knows what he does not know.” Lao Tzu once said. This attitude permeates both systems.
AFP’s designers were some of the most experienced system architects in the world. It was my privilege to work with them as a junior programmer fresh out of engineering school, which gave me an inside view of the development of this platform that brings so many of us together from around the world. The fundamental design they put in place has remained essentially unchanged for more than 30 years.
One of the reasons it hasn’t had to change is that it was designed to expand and adapt from the start. They didn’t know there would be JPEGs and PDFs and everything else, but the system’s functional towers could be updated to accommodate whatever the coming years would throw at them. When drafting the Constitution, the framers didn’t know about the Internet and airplanes, but, just like with AFP, there were certain things they wanted to avoid in their design. Specifically, they didn’t want it to be too restrictive. That way, both groups could create solid, lasting foundations on which adaptations can be built.
The AFP Consortium is a logical outgrowth of that approach, as it welcomes innovation and new perspectives to find new ways to build on AFP’s bedrock. Previously, after IBM developed AFP, competitive companies who used it had to wait for IBM/InfoPrint/Ricoh to evolve AFP before they could adapt their own practices. The senior leadership realized there was a lot of demand for AFP. If the architecture couldn’t keep up at the pace businesses needed it to, they might have ended up making their own changes, which would have made different iterations of AFP less flexible and more vendor-specific, fragmenting AFP and weakening its utility as a global platform. So the idea of an international consortium, regardless of members’ market competition with one another, was proposed and adopted – the birth of the AFP Consortium.
This evolution – an evolution to allow for evolution – was made with an eye entirely toward serving customers. IBM/InfoPrint/Ricoh could feasibly have kept AFP entirely in-house, releasing updates to which competitors could either adapt or not. But when competitors get left behind, so do their customers –including customers in multi-vendor environments, where the system is only as strong as its weakest link. If Company A hasn’t updated its use of AFP, its customers’ capabilities are limited, even if that customer also has AFP software and equipment from Company B, who has made the updates. The solution was to get Company A and Company B – and the other stakeholders around the world – together to talk about the challenges, wants and needs of their customers, so AFP could adapt to address them.
The AFP Consortium helps us make the most out of AFP’s built-in flexibility. The fact that its underlying design is so solid, that so much can be done to augment and modify it, means bringing in more perspectives that strengthen it. Just another reason I’m so proud, and so honored, to be playing a larger role in the AFP Consortium. Thank you to the many giants on whose shoulders we stand, and thank you to the many people still working tirelessly to improve AFP in ways we never could have dreamed of in 1984.