Indeed. The first step is commoditizing and genericizing mobile hardware, like what happened to the PC market in the 80s. Purism is taking a big leap at this, and I definitely want to encourage that.
You don't have to call it giving up. Go is pretty easy to pick up if you're used to high level languages. I would recommend reading a pretty short book called "concurrency in go" (Katherine Cox-Buday) for some really concise education on it.
IMO It should be feasible to build data bridges for integrating or syncing with related systems.
That said, as a developer I'd love it if I could track my more technical thoughts & needs without having to go to my enterprise tools where BA's run wild & confused. The trade-off of course being more dissonance and potentially a failure to advocate for this work in planning, unless you synchronize data somehow.
I love this because I started building a small utility to help me consistently track issues inside my project files like tickets/{folders}/{file
}.md inside my projects, because I do not need an enterprise level management system, and I also really like the idea of tickets moving and closing as a part of merges, IMO it provides a better context when looking through history.
This is clearly more elegant, though it adds a new dependency, which is OK.
>I also really like the idea of tickets moving and closing as a part of merges
I really like that, too, I wish we'd track our requirements in git instead of having an IBM enterprise solution which is slow, has a terrible web interface and no ability to diff requirements properly.
The more information is versioned in the same system, the better the coherence of the information.
> I also really like the idea of tickets moving and closing as a part of merges
So does that mean that bug reports are tied to branches? (I.e. depending on which branch you've checked out, you see a different list of bugs?) I wouldn't like that idea at all because how would you keep track of bugs (and related discussions) across branches? (For instance, having 10 branches would imply that you suddenly have 10 versions of the same bug discussion, too.)
I see more value in it for clear technical tasks with technical descriptions, and not so much for discussions. Then proposals can be peer-reviewed before accepted as work that needs to be done (as a merge request to master, for example).
Then another problem that comes along with that, especially for golang users, is that your master branch is getting bombarded with issue updates, causing what looks like releases, when there's no effective change.
I know this sounds like a cliche at this point, but volume 3 of Donald Knuth's "The Art of Computer Programming" goes into more depth on the theory that underpins these algorithms than anything else I've ever seen/read/heard of (in fairness, I haven't read OP's suggestion yet, though).
I agree with this, and I would also like to see more welfare programs separate from the insurance role. Insurance companies like to trick you into thinking you're getting a better deal because of them. That's not what insurance means. Keep those roles separate and straightforward.
I would love to see a company whose business model is making generic and standard consumer electronics parts that are small and powerful, with options to boot. I would love it if I could build & maintain my own mobile computer (AKA smartphone) just as I would build my own PC. Since taking my kindle voyage apart, I realize that this must be very doable. That thing is way less sophisticated than a raspberry pi, it just happens to be a form factor that I like to hold.
Probably not what you are looking for but I'm keeping an eye on Fairphone [1], a company that tries to ethically source for phone parts and ensures that you can repair the phone you buy from them.
I would love it if I could build & maintain my own mobile computer (AKA smartphone) just as I would build my own PC.
I would love to build and maintain my own PC, but I assume that Intel Management Engine (ME) or the equivilent is going to come with the CPU for the PC I build.
I would rather have a larger handheld device than my Nexus 5x if it meant I control the hardware and software on it. 2/3/4 I think can be worked out by the consumer market as long as standards can be crafted for modularity.
