GitLab, as an example, has been clear about having an "open core" business model[1] I appreciate that level of transparency. It gives me confidence that they understand their market and customers.
Naming matters. If a company can't or won't use the agreed-upon-by-the-software-development-community terminology on how the project is operated, it's souring to me. I also wonder if they (the company) understand what Open Source "is," specifically the responsibility that inherently comes with having an Open Source development/product model. In that circumstance, it feels like they have come to understand Open Source in the same vein that society once understood phrenology[2].
I'm going to be annoyingly pedantic here, apologies in advance. To me, what you're describing is an end state where the fetch/build + test is a state in which the developer is done with some task. But in my working reality, testing/building is a non-linear process that is iteratively run after some certain self-determined point-in-time.
>Ideally starting from a blank machine/VM you should be able to run a single script that get’s the latest, builds it locally, runs it successfully, and passes all tests.
This isn't automatic, and is a practice that is fairly standard today (And one I agree with). You have placed a requirement/line in the sand that says, "Only when I have ideal state should this pipeline run in linear time and output the final result, which are the return codes from tests." Your example has the user initiating the update of the upstream main, not some other process that runs git fetch on the Developer's behalf.
Your original comment, as I understand it, is contradictory to this point:
>or code to function on CI machine will also be automatically loaded into production and other developers machines.
All of us (I think) agree that auto-deployment to production is a desirable goal. But we all (I think) know that broken commits are routinely delivered to production, where "production" represents the sum of all production environments in the world. So while we can have a reasonable assumption that "Production is, or should be deployable all the time," that doesn't mean the state that is represented by Production is safe to run locally in my environment, unless I *specifically* request it. Since git doesn't have file-locking, some other team/PM/developer can decide it's time for <MASSIVE REFACTOR> that blows away my work/branch mistakenly (Or maybe even intentionally, especially if I work in an org that is terrible with communication), creating unnecessary merge conflicts/mental load. This happens in short-lived and long-lived feature branches.
In no setup, do I think it's ever safe to take away the developer's agency and let some other process keep my local machine in "sync." There are so many variables to account for that some daemon/service can't be aware of, to allow for automatic updating (and again automatic updating != user running `git fetch`).
From the perspective of the dev, if my local CI isn’t worth anything towards a merge and upstream CI is gospel why run locally? If I’m reasonably certain that the two jobs are duplicative in output it could be seen as wasted time, especially if I have a PM hounding for features. I don’t call that lazy, I call that a trade off. (coming from someone who is constantly running tests locally before pushing upstream)
The article posits an academic theory of CI that biases towards very narrow models of software development: Namely kubernetes, and namely orgs that have the budget to experiment in these types of models where developer trust is a nice to have, rather than regulatory compliance.
So as a thought experiment it’s neat, but knowing that most orgs will never need Kube and will never develop software like a FAANG, it just strikes me as clickbait given the title.
>will also be automatically loaded into production and other developers machines.
I’m assuming you are only submitting this as theoretical, because in the real world (where I’ve directly experienced this workflow) it’s a nightmare:
* Someone merges main which deletes working files in your feature branch. Automatic pushing/rebasing of main onto your feature branch creates needless work the moment you try to push upstream when git tries to ascertain state of local main.
* countless times I’ve hit bugs where if I try to merge “patch-a” from a common “feat-1” branch (meaning patch was cut from feat, not from main), but then main is updated by the auto-updater, I then have a messy working directory in which main’s new files are treated as unknown orphans and I have to spend time deleting these by hand.
I’m all for having my feat branch be up to date at merge time. But making it a rolling target is something git (from my perspective) hits the boundary of what git can reasonably do, and creates more pain than any type of positive DX
>Those 3 points are valid but not even the worst bits. It sounds like you are just griping about the switching cost issues, and didn't get much further than initial setup.
100%
My rule-of-thumb is that onboarding has to be *incredibly* easy; it's the front door of an application, the user's first substantial interactions. If it's not easy or streamlined, I start wondering how the rest of the UX is. And in this case, the front door muddied the carpet inside the doors of the software, and I couldn't figure out how to make the process easy for myself, as BW is feature-gapped in many places.
>Once you actually try to use BW in earnest, you'll find it's noticeably worse than 1PW in most ways. The most glaring is that it is meh at detecting login forms and poor at detecting new account signup. These are the 2 primary flows for a pw manager!
Yes, exactly. I'd argue that login form management is the single most important selling point of a password manager. I can roll my eyes, but deal with new account signup forms. But login forms with stellar autofill is what separates the wheat from the chaff, IMO.
>They've had quite long enough time already to do that. How long will you hold out hope?
Competition makes better product for all of us, I don't want to go back to the days of LastPass, So I'll cross my fingers for them, but won't return as a customer after this initial billing cycle.
>Anyway the primary use case I care about is sharing, not self-mgmt.
I'm the inverse; self-management is more important. The only sharing I need is with my partner, which we don't do much of, considering most important shared stuff has accounts for each of us. KeePass is simply for backup purposes, but I haven't decided one way or another where I'll land between them and Vault. I lean towards Vault (Full disclosure: I work for Hashicorp) mostly because I'm more familiar with the APIs than I am with KeePass's plugin/extension frameworks.
This is very salient, I just left some feedback related to lack of functionality, in their community forums yesterday. I bought a subscription to use Bitwarden against 1Password, trying to switch from 1P to BW. I dislike 1P's arrogant customer service (Read their community forums for about an hour, and look at many of the responses from staff regarding feature requests) and my attitude towards them really soured when they flipped the switch on perpetual licensing.
So I was excited and went in with an open mind, and delighted to be supporting an open source company:
* The initial migration went off to a bad start as it didn't include everything from 1Password. Seemingly random data, and some attachments were missing. If I remember correctly, timestamps/creation dates didn't seem to migrate over, and some whole passwords weren't brought over, but no errors were reported from their migrator.
* When I went to setup my vault after the migration, I was disappointed to see that there was a distinct lack of password types. I have software licenses, credit cards, API keys, regular passwords, recovery tokens, (non-critical) GPG keys, SSH keys, etc etc that I store in my vault. BW only had/has 4 item types to choose from, which just isn't suitable if you want to correctly track the types of items for organization and filtering. There is support for custom fields, but it just isn't the same..
* No support for tagging. I tried to setup a nested folder structure alternatively, but the UX was not easy to use in the desktop application (I was assuming I could do something similar to a `mkdir -p path/to/nested/folder` but BW only allowed me to create a single folder item at a time. For 500 password items, and different "buckets" I keep to organize, I ended up abandoning folders and just kept everything in the root in a mish-mash setup.
I get that it's small and open source, and you have to temper expectations when comparing David (BW) vs Goliath (1P), but BW seems to have earned more community trust, and has an engaged community of fans. BW could absolutely provide a better experience than 1P both from a customer empathy standpoint, and from a product delivery perspective. But point 2 makes a failure (IMO) on point 1. Reading through their community forums, many of these (What I'd consider) table-stakes features have been left to rot on the tree of technical debt. Which makes me sad, because I'd pay a lot more than their current pricing model if they kept an open source attitude towards the product and could deliver more than just a "We're working on it! Stay tuned!" attitude after years of community comments. I'm gonna stick with 1P when the licenses come up for renewal, and use KeePass or Vault as an on-prem backup solution.
I truly, truly hope BW succeeds, because I'd love to move away from my current setup. But I'm not willing to capitulate my workflow because the company can't deliver on highly-requested/highly-coveted features.
I don't squarely put the blame on BW. This feels very common in the saas lifecycle: A feature has some sort of engagement/revenue metric attached to it, for growth tracking. Whether correlation is correct is a debate for another time, but many of these core features have an opaque effect on revenue or engagement (If you're a cynical product manager, an efficient tagging system correlates to less engagement, because I'm spending less time rooting around the user interface, which is less opportunity to use the application minute-by-minute), or it's considered plumbing-type work in which the revenue/engagement potential is spread out across the entire userbase, so the effect is less explosive (SSH key management[1], a niche feature requested by a loud subset of 1P users had huge awareness. But external sharing of items[2] was something I heard very little about, even though (objectively) external sharing casts a wider a shadow of net-new 1P users.
I digress. This just reminded me of the frustration I have with software: Feels like everything I want to use is always missing some key element that I have to trade off for another key element when looking at competitors.
* What is the amount of storage provided for users?
* How is content managed when offline? If/When I start traveling more, there will be times when I like to read without internet access.