I agree, let me take a stab at starting the conversation.
First of all, huge respect to Slava for this writeup. Having your startup fail is hard and it is not the time you want to blog about it. RethinkDB going broke was a sad thing to see for me, I can't imagine how it felt for him.
I think the analysis of the two root causes (hard market, focus on the wrong metrics) is accurate. It is very sad to see that in the end correctness doesn't win the day, not even for databases.
Since I run a startup too I can't help but apply his criteria to GitLab.
3. A use case => we're making GitLab an integrated tool with a broad scope https://about.gitlab.com/direction/#scope A good way to develop software from idea to production.
I hope the above list doesn't come across as pretentious. I welcome pushback and the opportunity to talk more about the OP.
I think the OP premise that it is hard to make money in the cloud is accurate. We're spending hundreds of thousands of dollars to make GitLab.com run and revenue takes a long time to grow. Selling on-premises software products has higher margins than a service.
BTW I appreciate the shoutout to GitLab as one of the five exceptions that are doing well in the open source developer market.
I'll attempt to add to this. I might be stating things that are a bit controversial here.
1 thing we are always transparent with users about is how our business model works. 1 of my favorite videos on the internet about this is [1]. We are very much based on closed source for making revenue. This has actually helped with our community a lot.
We are basically focused on closed source solutions for specific verticals. The only way to get clients to pay is to make something more efficient or don't open source/core it. For open source companies there is always a trade off of community vs customers. You have to find a hard line and stick to it.
Community is great, but most of those people won't want to pay you. You can try to convert them, but that takes a lot of time and isn't the best path to market.
We strive to provide a great base line experience to our users, but a few of the things we have found in practice that helps:
1. Features have customer names on them
2. There's a mass of community interest in a specific feature
You have to be careful about where time is spent.
It's very easy to mistake "users" for "customers".
I wish slava and co the best of luck and really appreciate their post mortem. 1 thing we've learned as an infra company is "be as close to the app as possible". In our case the bulk of what we focus on is banking/telco anomaly detection.
It's a straight forward revenue making product that can benefit from deep learning. The great thing is we can grow in to other use cases later on if we find something else interesting to work on.
Even seen this backfire at many commercial companies. Adding whatever features a company is willing to pay for will often pull a product in multiple, incompatible directions.
I'll give you that. In my case, a lot of what we do is look for numbers and how well it fits our main application area.
You definitely have a valid point here though.
That actually goes hand in hand with "users look like customers". Also: "Not every customer is a good customer."
EDIT: Originally written as a response to u/probinso, but got way too long. I'm a novice here, so any thoughts/anecdotes/(dis)agreements/anything are greatly appreciated.
+1 - I would like an invite too! Back to the article, this is probably the topic I've thought most about recently.
In the past year I have taken serious interest in jazz musicianship, specifically improvisation. I'd like to get significantly better at both programming and jazz improvisation as fast as possible, so relentlessly optimizing my practice, or "practicing practice", has been my #1 goal. I have a decent approach for music, but I'm still looking for one for programming.
Here are a few of my amateur approaches to "deliberate practice" regarding music:
- The first and most obvious thing I learned was that you can't improvise what you can't physically play. So clearly, deliberate practice is required to gain the ability to play anything. I've seen and heard this referred to as a musician's "chops". To develop this, I practice scales, arpeggios, chords, licks, songs I've transcribed, and other targeted exercises.
- To improvise an appropriate melody I have to 1) hear and understand the music outside the melody, 2) create a good melody over it in my head, then 3) translate and play the melody in my head. There is a lot of overlap in the practice for these three, which mostly sums to ear training, sight reading, sight singing, listening to a bunch music, transcribing and analyzing it, and repeated, concentrated attention to how the harmony + rhythm of songs work and how the melody fits over/in that.
- Learning lots of music theory + applied practice of it, with the ultimate goal of using knowledge intuitively rather than actively. The key assumption here is that my music knowledge has to be intuitive, because I won't have time to think about all this stuff when improvising. So I'm hoping that consuming thousands of resources (songs, books, talks, paid lessons), actively using learned information, and gaining lots of experience will make improvisation natural, subconsciously feasible, or at the very least much easier.
- Playing and improvising with others a lot.
I generally think of all of this as 1) developing fundamentals and technical skills 2) discovering and adding new things 3) applying knowledge 4) reviewing assumptions, making changes 5) iterating. Then, maybe enough iteration => experience, and enough creativity + experience will lead to the craftsmanship I need?
This basic approach to music is good enough for me right now, but I'd like to start the same process with making software. So finally, the question in the article - "What is deliberate practice for programmers?". I don’t have the answer but I’d sure like to know.
I could review all the knowledge I gained from CS in university. Implement a bunch of stuff, like DS, algorithms, apps, low level mechanisms? Read a bunch of highly rated technical books? Talk to people smarter and more experienced than me? Go work at a company that says it's invested in it's employees growth?
This is all great, but it doesn't seem like deliberate practice in the way that my practice for improvisation does. I would like to become a great programmer, but the problem is that I just want to be great at all things programming. I guess I have more specific end goal in terms of music. Maybe it's that I don't really know what I want in terms of programming? Perhaps I need to specialize, though it's a little early for me to know where. It's very frustrating knowing that I want to get better, am willing to "put in the work", but don't know what “work" I should be doing.
Programming chops aren't much different than music chops. Guitar? You understand your instrument. Using it is intuitive, right? You have programming tools (editor/IDE, language, libraries). You started off by learning scales--learn your dev tools until you don't have to think about what you're doing--it just happens. Find rough edges? Fix them (extend your environment, make keyboard macros, whatver it is you notice as a "hitch" in your process).
Music theory: how things (e.g., notes, chord progressions, etc.) relate to each other. Same thing with code: languages, libraries/frameworks, persistence mechanisms, messaging systems have similar relationships. Each solves a particular problem, often in very different ways (e.g., graph DBs vs key/value store vs RDBMS). Understand those relationships and how to take advantage of them--and just like improv, how the "rules" can be bent to solve a particular problem (HTF do I resolve this progression I've backed myself into).
I personally don't spend a lot of time anymore dealing with algorithms, but that's largely because the programming I do these days doesn't really require much deep thought at that low of a level (for better or worse). Data structures are always key, but for me, deep knowledge of them isn't necessary--only enough to understand what's more or less the "best" for a task is sufficient.
Understand different paradigms of programming languages, persistence, messaging, etc. just like you should have at least some understanding of alternate tunings, different musical structures (the best musicians I know have exposure to at least some level of a wide variety of musical traditions; have a go at some Indonesian gamelan, some Ghanian drumming, kotos or zhengs). Understanding the differences between things is often more important than having a deep understanding of those things.
Nice. I've been thinking a lot about writing a interactive blog series of something similar (music fundamentals for CS people). It'll probably be a while before I start writing that though.
I think the biggest thing that's missing at the moment is a section on rhythm/time. I'm sure you have plans for that. Looking forward to seeing finished course.
Depends on how ready you want it to be, and how much free time I have. At least for the 'up to the keyboard working' version should be maybe a month max, after that, it depends on how fast I can get new code written.
I just published my first piece! Planning to mostly post long-form articles on non-traditional software stuff.
--
* https://www.heneli.dev/blog/fearless-tinkering-is-functional - Five-part series on functional programming and its advantages