At the beginning of this month, I published a blog post titled 'NymphCast: A casual attempt at an open alternative to ChromeCast and kin' [1]. This got picked up a number of tech websites [2][3][4][5][6] over the past weeks. Explaining to people just what the NymphCast project [7] is about, what it can do right now and perhaps most importantly getting feedback about how people perceive the project based on the information that is out there right now, all of that has been quite enlightening.
As I wrote that original blog post, I was still in the process of finishing up the implementation of the basic features of the initial (v0.1) release. Meaning that it was a definite prototype, with the scaffolding obscuring much of what was already there, but also what wasn't there yet. Things like seeking through files being streamed, for example. Essentially with the way the project got presented in those articles, it sounded as if it was a ready to use solution folk could just slap onto their Raspberry Pi compute things and be off to the races.
Suffice it to say that this caused a bit of confusion in the commentary to those articles.
I have since put a product page with documentation [8] over at the Nyanko website, with information on how to develop these mysterious 'NymphCast apps' using the AngelScript programming language. That partially addresses the point of where in blazen's name the documentation for any of it is. The other points raised were about its feature set and what it will support in the future, as well as a host of related questions.
The tricky thing there is that as I had formulated it in my blog post, the project is first and foremost a fun hobby project of mine to scratch this itch of there not being a proper open source, cross-platform solution that is like ChromeCast or AirPlay. Of course I am open to extending the feature set to add things that do not necessarily scratch my own itches. A lot of features that got suggested are interesting from a development and technical point of view, so I see them as interesting challenges to learn from and grow as a developer.
Yet things are never quite that rosy.
Even though I implemented the last and most invasive feature into NymphCast a few weeks ago (full seeking support), this only meant that the rule of thumb that I use for estimating required development time kicked in. This rule is the '10/90/90' rule, as in the workload in any (software) project is 10% planning, 90% implementing (100%, or what usually gets scheduled) and 90% testing/debugging (making a total of 190%, for those keeping score). A rough estimate on development time for NymphCast is that I spent about a month (full-time) on it. This means that with testing time having kicked in, I'll have a few (full-time) weeks of testing ahead of me, including the Alpha, Beta and Release Candidate phases.
Here of course one can cheat, as is common in (commercial) software development; instead of accepting the 10/90/90 rule, it gets instead crammed into something like '10/90/10', with just enough testing done that nothing is all too obviously broken for the first users. This often leads to the other 80% of testing being combined into subsequent development cycles. If I were to follow this approach, the v0.2 development version of NymphCast would involve a lot of catching up on bugs and issues that lived on due to the shortened v0.1 test cycle.
It's quite possible that these latent bugs and issues from v0.1 would interfere with v0.2 development, even slowing it down, as it would often be unclear whether a new feature or change created a regression, or whether one merely tripped over a hidden bug. This is why I'm no big fan of shortened test cycles. Of course, this does mean that you end up disappointing end-users (or heavens forbid, customers). Instead, I prefer to just grind my way through testing, torturing the software using countless (intended and unintended) usage scenarios to shake out bugs. Let me just say that I fixed a whole stack of issues between the first (alpha1) and second (alpha2) alpha releases.
Here of course the consideration is that end-users ultimately want to have something that Just Works (tm), with only a certain tolerance for bugs and issues. Is having them wait longer worse than giving them a broken product?
All of this is more or less a long-winded way to say that the rush of popularity (nearly 50,000 views on that one blog post, and over 1,100 stars on the Github project) was unexpected and perhaps somewhat premature. Possibly.
Though I very much appreciate the attention, it does put me into a bit of a pickle. On one hand there's now this sudden popularity, that will likely die down if the project doesn't deliver, yet going into full-time development mode to get the v0.1 release and beyond out of the door isn't feasible either. It's, after all, a hobby project. Hobby projects do not pay the bills, or put food on the table.
It seems almost as if the only real option is to let the project slip back into obscurity, while I slowly work away on it over the next months and perhaps years, until it's ready(-ish) for prime time.
Time will tell, I guess.
Maya
[1] https://mayaposch.blogspot.com/2020/03/nymphcast-casual-attempt-at-open.html
[2] https://tweakers.net/geek/164126/ontwikkelaar-maakt-open-source-chromecast-alternatief.html
[3] https://www.reddit.com/r/linux/comments/fhdnav/nymphcast_an_opensource_alternative_to_chromecast/
[4] https://www.tomshardware.com/news/using-raspberry-pi-like-a-chromecast-open-source-nymphcast-project-makes-it-happen
[5] https://www.kitguru.net/lifestyle/mobile/accessories/christopher-nohall/nymphcast-turns-your-raspberry-pi-into-a-streaming-device/
[6] https://news.ycombinator.com/item?id=22457351
[7] https://github.com/MayaPosch/NymphCast
[8] http://nyanko.ws/nymphcast.php
No comments:
Post a Comment