In this post you will learn about my experience as a non-developer helping to take a closed source software project, a non-linear visual story framework for IOS Swift, into the Open Source realm and develop a demo for it.
Here is a brief overview of the post’s content:
- Project Background and Team
- The Process
- Learning
- Solving Problems
- Where this path has taken me today.
Project Background and Team
It has been about 8 months now that I started contributing to a new Open-Source project called Boken Engine Boken Engine – An iOS Swift framework for creating slides-based, non-linear visual stories and presentations. The project however, started beginning of last year as a closed source development for one of my former employer’s HYVE customers.
I got involved since our customer wanted us to explore among other topics the business aspects for this new Open-Source project. so that in January 2021 I started collaborating as a member of a team of 4.
My colleagues were all software developers, but they all had little experience with Open-Source projects and were thus also interested in working on the project.
The Process
The steps we took in brief for converting the closed source project into Open Source are essentially 3 for the various topics that we looked into methodically:
- Research
- Discuss & Decide
- Implement
Research and Topics
There were different topics that had to be looked into so that we split up the research and the code creation for the nonlinear visual story framework.
We approached different topics during our research, touching among others on:
- Where to host it
- Licensing
- Community management
- Business modelling
- Marketing strategy
In my case, I was to investigate the different possible business models that existed for Open-Source Software projects and document all these, which I did.
All was documented and used to take decisions for the development of the project.
We tried to make the process completely transparent and useful for others, who ever considered embarking on the Open-Source Software adventure. Here you have an overview of the documentation that was generated during the process.
If you are curious, you can find this information here.
Discussing & Deciding
Each time some research was done we would discuss it internally and decide on it.
We tried to make our thought process transparent and document it in such a way that it would create a precedent on how things have been done for anyone who were to join later.
It became evident from the research and our internal discussions that as a small team it was easy to make decisions but with time the process had to be adapted once the project community got some traction.
Implementation
Once we had decided on something we did it. For instance, the first thing we had to decide on, was where to host our Open-Source project. We decided to do so on GitHub. Given that none of us had had much experience in the contribution and organization of Open-Source projects we learned mostly by doing as the project developed. Fact is we are still doing so, which makes it even more interesting for me.
Learning
It has been a steep learning curve, especially for me whom I had not used Git before and had to get used to it. On the other hand, it has also been an exciting project so far since all my colleagues had to learn new tools and look for solutions to each problem that we encountered. All the problems that we encountered we discussed and documented when it was of technical nature for future reference, learning how to use the Discussion feature by Github etc.
Solving Problems
As the project progressed, we ran into situations where we had no experience at all, and our initial plans were not possible, so we had to improvise and look for solutions. One of these was when the moment came to hire an external artist for the demo story’s background images and character sprites.
We selected an artist but at the last moment with already the deadline coming close he could not work with us. As a team we decided to do everything in-house since we had almost all the necessary skills. One of my colleagues took care of the background images and I took charge of the sprites. I had never published a piece of art of mine, nor created art for such a large project following specific requirements, and less so digitally so that it was a steep learning curve for me.
In my specific case I tested and learned to use 2 different digital drawing applications and created artwork with it. The applications that I used were Affinity Designer and the other Corel Painter 2022.
Here is a small sample of the Art that I created for the Iakkai Saga App:
The hardware that I used was a WACOM Cintiq 13” tablet. It was a great experience which I really enjoyed, and I can only recommend both application and the tablet. In my case in the end, I preferred the Affinity application for its lower price tag, though I must say that it is not as complete as Corel Painter 2022 which offer many other possible workflows. Some of my colleagues also learned and documented it, for example here is a link to two articles by my colleagues:
If you want to read more articles in the future here is our website and blog: https://www.boken-engine.dev/
Where the Path has taken Me
As of today, I continue contributing to the Boken project, helping in non-development topics, such as art creation, reviewing of written texts, etc. and it feels great to be part of a team and creating something, especially since the Demo is now published in its first version.
Our Demo is called “Iakkai – Curse of Blood”. We got it approved last week and you can find it here. Besides this experience has opened my eyes to new interesting learning topics and skills that I can develop but also opened a new opportunity that I have decided to explore.
I can only encourage anyone to check out OSS projects and contribute to these even if they are not developers, since you can always add value with your knowledge and time. Here is a post in case you want to know a little more about it: https://opensource.com/life/16/1/8-ways-contribute-open-source-without-writing-code.