I’ve been sitting in my bath and pondering publishing platforms. Specifically, how long it takes to build them. We get asked this all the time. So… here is my very non-scientific answer to the very open ended ‘how long will it take?’.
For a start, let’s measure it in person years. 1 person working one year = 1 person year. A calendar year, on the other hand, is an actual year ie 1 year elapsed.
The answer, I think, is around about 3-6 person (dev) years + 1 year management/design/UX etc. 6 (+1) person years is at the top end for the old skool way of building platforms (building everything yourself). If you build with PubSweet I think we have that down to about 3-4 (+1) person years. So 1 developer will take 3-4 calendar years (with management/ux/design occurring in parallel).
Adding more devs lessens the time. That means if you have 2 devs its around 1.5-2 calendar years. 4 devs gets it lower but at a slower ramp down. Maybe 1 calendar year.
I think, again incredibly unscientific, that the 1 year management/ux/design is both 1 person year and a static calendar year…ie. no matter how many developers you have, you still need one or so cal year in total for nailing down details, improving UX, look n feel etc…so even if you get dev down to 1 year, its hard to see how you can reduce the 1 calendar year management/ux/design. Theres just a lot of to and fro and thinky time required for these parts. Thankfully however most of this can be done in parallel to dev work.
That seems about right from what I have seen in the outside world and inside the Coko community. The new improved PubSweet dev times don’t account for significant complexity (eg very experimental approaches or situations with many legacy integrations or systems which themselves contain significant new applications like web based word processors/pagination engines/JATS Editors etc – each of which will take longer). It also doesn’t account for significant reusability (which will cut down the time). The numbers are based on a team building a ‘typical’ journal or book production workflow from the ground up on PubSweet and re-using some existing components but building most themselves.
I think as we grow this timeline will drop through the floor with significant re-usability and more people to learn from. Both of which are conditions that will be met as the community grows. We have already shaved 2 or so years at least from such endeavors which is significant and I think we will see it drop even more. Those that come later will benefit greatly from what is happening now, but even now we are making some fantastic efficiencies.
This is obviously totally based on nothing but observation of dev time across 10-12 years on a few dozen publishing platforms I’ve been involved in. Very anecdotal but not nothing.