Solo founder at Emysound[1].
Started 10 years ago as an open-source project, building an algorithm for audio fingerprinting. Added a commercial offering, selling storage built specifically for audio fingerprints, targeting enterprise customers. Since the offering was too technical (it's hard to sell solutions to problems that are too narrow and domain-specific), pivoted to more "business-oriented problems". This last year's pivot is a chance to finally grow. Running a business in single-player mode is, at times, too stressful. Aside from the technical part, which I very much enjoy, I need to wear marketing, sales, and customer support hats.
My goal for the next year is just to work fewer hours. Covid pushed my work habit to the extreme, and I need to rebalance.
1. Read more books, less social media/news.
2. Spend more time with my friends. I haven't seen some of them IRL for more than a year.
3. Exercise more, play tennis with my daughter, spend quality time with my kids.
4. Spend more time with my parents. They've become visibly older in the last years, an observation that scares me.
5. Focus more on marketing for the businesses that I've bootstrapped. All the shiny new features that are developed are not as important as getting more people to use your product.
6. Promote open-source project to 1k GitHub stars[1]. I know it isn't very meaningful, but it's just nice to receive a bit of recognition from the community.
7. Enjoy life, don't stress about all the little things that happen along the way.
Are the open source work and the business marketing part of/all of the “work” that you want to do less of? If so, what is your plan for balancing doing less of it while still trying to accomplish those goals?
I'm really not good at marketing. Essentially I have to learn how to do it first. I plan to spend more time learning this new skill and then applying it. I've been recommended this [1] course, and if anyone can recommend something that worked for them, that'd be great.
Balancing it with other duties is going to be hard, though I will try to explicitly divide my time into "one-week marketing / one-week dev work." Inside each week, I will try to have days fully reserved for non-work activities.
Programming keeps me in this perpetual cycle of "one more thing for today/this week" which locks me in the IDE without end in sight. I will postpone any dev work that needs to be done until "dev work week" arrives.
This reminded me of Sergiu Celibidache, a revered and criticized conductor who had a different opinion about tempo on major classical works.
He viewed his performances more as "experiences" and certainly pushed the boundaries of the conventional style of playing classical music.
I really like his renditions of Bruckner, and the ending for Symphony N4 probably best describes why [1]. He does not rush, letting the music sync in, undoubtedly different from the "right" version.
Not being afraid of criticism is an essential quality of people who discover new things. Smart people often get dragged into the "correct", "proper" way of thinking, doing science, playing music, drawing, or doing other creative work. This is the best way to learn, but unfortunately, you need to go on an unbeaten path that is often criticized and even ostracized to discover new things. The life of Van Gogh and many others is quite an example of that.
For binary vectors you can choose a different distance metric (not geometric one, i.e. Jaccard) that can be used to effectively hash similar data points into similar buckets.
Treating your binary vector as a set allows you to use min-hashing as your LSH schema (min-hashing is just a random permutation of the given set). This simple trick makes LSH with min-hashing quite a powerful tool for binary vectors that are extensively used in recommenders systems and other domains.
I've used LSH + Min-Hash for image search (and subsequently for audio fingerprinting). If interested, I've blogged about it here [1].
If you delist your Shopify app from the app store you will not have to pay the 20% monthly commission from the new customers. It also means your app is private, and you will have to invest in your distribution channel now. Shopify stores can install it as a Private App, which means you will need to find new customers on your own.
On a different note, I wouldn't recommend building an app that is strongly integrated into the Shopify platform due to a myriad of reasons.
Shopify App store will not give you enough exposure to grow your customer base naturally, you will have to invest in your distribution channel anyways, but now you are tied to a 20% commission since your app is public.
App store ranking system is heavily tuned towards the rate of installations your app has, which means products that offer free, or very cheap pricing plans are getting to the front page. If you offer free or very cheap pricing you will get inundated with customer support requests. The biggest chunk of Shopify customers, have very little understanding how to run an e-commerce store. Handling these requests will be a nightmare. This also means that the Shopify App store is not used anymore by stores that are running on Professional or Shopify Plus platforms, since it is full of apps that are borderline scam, and they can't find valuable services by a simple search.
Shopify understands this as well, that's why they've created Shopify Plus Certified App Store https://www.shopify.com/plus/partners/technology, which is essentially a curated Shopify App store targeting customers who are not afraid of paying money for valuable services. Getting there is not easy since the certification process is not transparent (we've applied but not heard anything from Shopify since then).
Also, Shopify integrates new features into its platform every year getting into more and more verticals. This essentially means that if you build an app that provides important e-commerce functionality, Shopify will probably release the same feature integrated natively into their platform.
All in all, don't bet on the Shopify App Store distribution channel, it is just not worth it.
There's a difference between delisting your app from the Shopify App Store and making it private (now called custom). A delisted app still needs to use Shopify's billing system and pay the 20% fee even if you find new customers yourself. If your Shopify app is private (custom) then it doesn't need to use Shopify's billing system but then it can't be installed by more than 1 merchant. So Shopify has basically created a catch 22. If you want your app to be installed by more than 1 merchant even if it's not on the Shopify App Store then you're required to pay them a fee. For reference, Shopify made this change at the end of 2019: https://www.shopify.com/partners/blog/shopify-public-apps
Very thoughtful point. I was concerned about it as well. Rushing a half-backed vaccine that has serious side-effects will fuel antivaxxers for decades.
There has actually been something like this during the swine flu pandemic. There was a vaccine that is believed to have caused some cases of narcolepsy. This was a real, bad sideeffect with a vaccine that was rushed to market.
Surprisingly this isn't a big talking point in antivaccine circles. Yeah you'll hear about it sometimes, but compare it to the number of times you hear "somethingsomething MMR aluminium autism" which is all debunked bullshit - you'll hear that far more often.
What I want to say is: Antivaccine people largely don't care about real issues with vaccines. They're happy with their pseudoscientific nonsense, that's good enough for them to reject every vaccine ever made.
One of the most challenging things in growing a software product is managing complexity. If you are designing a product for future use cases, you add complexity upfront. To keep a healthy balance, I try to follow simple guidelines:
* Focus on the current assignment. Implement it using clean code principles, don't overthink the problem.
* Rather than spending time on design decisions, allocate time on handling edge-cases. These will save you from PageDuty alerts.
* Plan excessive for future use-cases only around data models that insert/read into the database. Data migration is super-painful. A more generic design around your database is almost always preferable.
* Have a feature toggling[1] service in your codebase. It will provide you with a better understanding of how you can implement new features alongside existing codebase in the same branch. Releasing features from long-running separate branches is almost always a wrong decision.
* Always keep in mind time-constraints and how urgent is the requested functionality. Don't let perfection be the enemy of productivity.
* Have a process in place that allows for the technical debt tasks to be tackled independently. It helps fix some bad design decisions, which become apparent in light of new requirements.
There are a couple of concepts in F# that I really like:
* actor-based approach to concurrency[1]. Very useful when you want to design your code lock-free. Treating instances as agents that read messages from a mailbox, frees the developer from using low-level threading primitives. First time I've used this approach in production with AKKA and Scala. In F# it is much cleaner because the language itself is built on a better platform.
* exhaustive pattern matching[2]. Writing in F# means using pattern matching a lot. Exhaustive matching gives you the confidence to refactor and maintain your code. The compiler will warn you when adding a new value in your type and not covering the execution path that uses it. It catches a lot of errors before you even push the changes to CI.
* obviously immutability, conciseness, currying, these have been mentioned so far by others.
One nitpick in F# are Exceptions [3]. They approached it similarly to how it is done in C#. You are allowed to define and throw an exception that will "jump" somewhere in the execution path.
I prefer when a method returns Option-style types. This way, you know what to expect from a call, and pattern matches on the result without adding one more execution path in your code, which covers exceptions separately. It was added to support C# style error handling, though I very much prefer an error-code-based approach.
If you want a more interactive source you can play with python notebooks from the music information retrieval site [2]. I've found it helpful, as you try some of the described music theory concepts in a programming environment.
Shameless plug, I've also written about how audio fingerprinting works [3], which touches on some of the topics regarding music theory.
I've been working on SoundFingerprinting [1] for almost ten years now. Its Shazam for developers. First 8 years I worked mostly during my free time and weekends. 2 years ago, I decided to monetize the storage for the fingerprints. There is a MIT licensed version of the storage [2], and a commercial one [3], which is fine-tuned for thousands of hours of audio or video content. If you are an enterprise customer, you will essentially need it at some point, and will most probably have no problems paying for it.
Overall I invested a lot more time in it than the monetary reward I received. I don't complain since I enjoy working on audio/video fingerprinting and databases. On top of it, the pay at this stage is on par with a regular SE job with the bonus of working on things that I enjoy. I can call it a bootstrapped business now.
In some sense, I think about opensource similar to the work of art. You do it because you genuinely like to create/build things and showcase them to the general public. You don't do it because of the monetary reward. A good writer is one that has to say something, not one who writes for the sole purpose of getting on the NT bestselling list. Opensource is similar.
Nice to see an open source audio fingerprint. I once interviewed at Mediaguide (now defunct?) who scanned radio broadcasts so they could sell reporting to advertisers when their ads ran, and record labels when their songs played. There's probably a ton more applications.
Radio/TV broadcast analytics is the most frequent use case. At least I receive a significant amount of questions regarding it, so the library has been optimized for this task. YouTube ads detection is also an interesting case that falls in this category.
Other use cases are divided between game development, repeating content detection, robocalls detection, or just iOS/Android apps for Shazam like style features.
Surprisingly a couple of times, I was asked about recognizing birds by their singing. The library can't do it, but it is something I am thinking about exploring one day.
> Surprisingly a couple of times, I was asked about recognizing birds by their singing. The library can't do it, but it is something I am thinking about exploring one day.
[1] - https://emysound.com [2] - https://github.com/AddictedCS/soundfingerprinting