Hi all sorry I’m late to this epic party. This is an important topic so thank you to all who have contributed and will contribute.
My perspective is biased towards the realities of production. By that I mean:
a) it’s impossible to plan for every possibility and the ones you can plan for will change many times
b) software development is very expensive
c) there is no one solution for every use case
My other perspective is that of a software developer, which I am full-time for my day job. My experience there has taught me that you only build the minimum of what you need to get the most impactful result. From there, you only add features when you need them, and even then we avoid master plans and instead opt for incremental builds.
So, what does that mean for Kinograph and this idea of software we can all benefit from? Stick with me, I have been thinking about this off and on for years and this is the first time I’m trying to articulate it so I might ramble a bit…
Here are steps I think would be useful to take:
-
Research user workflows and desired outcomes. We are making assumptions about other people’s workflows based on our own knowledge and experience. Collecting information directly from users about what they want and what they already do/have is an essential step in meeting our audience where they are instead of giving them something we think is what they want.
-
Map out existing solutions and which workflows or parts of workflows they solve for already. Both paid and unpaid solutions should be considered. What are the tradeoffs? What gaps exist? What open source solutions exist we haven’t found yet?
-
Make a list of prioritized features to build. Similar to the 80/20 principle, what are the most impactful features we can build with the least amount of effort? From there, we work our way up the complexity ladder iteratively, releasing them one at a time instead of building “the perfect” software and dropping it all at once and hoping it’s what people want. This will allow us to be efficient with our time and get feedback throughout the development process from our users.
-
Create ownership of features. When we have our features, I think it best to form teams for each of those features so that we build real ownership and accountability for our product. Even if we hand parts of it to paid developers, it’s important that we make the design decisions ourselves, from the overall software architecture to the appearance of our GUI. This will ensure long-term continuity as well as a shared sense of responsibility.
-
Take inventory of our resources and scope what we think we can do and what we might need help with. Before we start asking for money, we should know exactly what we’re asking people to support. And they should be able to see mock-ups, written documentation about our decisions, and clear structure in place for project management and reporting back. That all happens as a result of the previous steps. We may surprise ourselves and have much less to build than we thought, or the opposite. Until we take inventory we won’t know.
Lastly, I encourage everyone to read the text I just published on the wiki home page, particularly the “Design Principles” section. This is a framework for us to make decisions big and small, such as this one surrounding software.
My suggestion is that we start this software endeavor as a group discussion focused on defining our design principles for the software. Then, as we walk through the list above, we can refer to our principles as a group when in doubt to help us find our way.
Here are some examples below. These are meant only as a starting point.
- Affordable - Wherever possible, we should encourage the use of already available tools instead of reinventing the wheel (unless that wheel is out of reach financially or legally). Additionally, what are the most efficient tools and design patterns to achieve the desired outcomes?
- Flexible - our software architecture should be loosely coupled so that new features are unlikely to break new ones and if a user wants to modify a feature, they are unlikely to break anything other than that one feature.
- Accessible - software should be written in a language that is common and which balances performance with ease of learning so as to encourage beginner coders to contribute. Design patterns should be easy to read and build upon. Ease of fixing and improving a feature should be prioritized over it’s clever complexity.
- Repeatable - choosing a software stack that is likely to last a long time and not dependent on shiny new things that tend to fade or need constant upgrading. Also, features should follow a pattern so that it is easy for developers to take an existing feature as a starting point for making their own.
- Good enough - for now, this means supporting our pilot partners in getting from raw scans to viewable movie files. This may mean our interface is ugly for a while, or that our list of features is very very small. As long as we provide an a workable solution for users to attain their scanning goals using existing options and/or our software, then that is good enough.
IN OTHER WORDS…
Let’s focus on how we build first before we dive into a list of features.
And when we do start a list of features, let’s start with a non-feature, the core architecture. I believe it will be something like the Linux project. There will be a “kernel” which will act as an interface and all features will be attached to the core but not each other. Our first job after answering the above general questions will then be to design this architecture and test it with a minimal feature set.
Okay, that’s enough for now. I look forward to and welcome your thoughts and reactions!
Using a projector as the transport is fine for a dailies scanner, but doing the old archival film you’re talking about will likely require multiple attempts to scan per reel very often, and that’s where the benefit will come in with using something that’s actually designed to scan film (if you can secure funding).