Depends on the size, but I have seen a non-trivial number of GitHub projects that reference an .mp4 served by raw.githubuserassets.com in their readme
I would suspect the cheapest way of doing that is to create an issue, drag the mp4 onto it, and then you have a stable reference to use from within the readme
My thought for shorter trials: If something more important derailed the trial then the product isn’t solving a problem with enough urgency for you and you were unlikely to convert.
Moby is the fedora like oss project and docker is the RHEL like commercial product. Purely a clever rebranding job. Timing is perfect - now that enterprise is adopting the technology, when you tell your boss you adopted moby he/she will say- but the CTO wants to be seen as being innovative for adopting this new technology and ita called docker not moby!
> but the CTO wants to be seen as being innovative for adopting this new technology and ita called docker not moby!
I see this kind of cynicism / snark all the time on HN (especially when it comes to Docker) but is it really warranted? Surely it's the rare exception? I've never met senior people who couldn't understand the naming difference between the open source version of a thing and the enterprise-branded version. Or a CEO or President. They're not morons.
This seems like cheap shots for upvotes. Or am I wrong?
I don't think your wrong. Someone being that entitled and ignorant must be the rare exception in 2017. Maybe I'm in a bubble too.
The conversation usually goes like this with my folk:
I get it, Moby is the OSS version and can be easily stood up and you don't see the need for extra cost. I'm glad you're trying to reduce expenses, but I don't mind paying for 24x7 Enterprise Support and it gives me piece of mind and priority escalation support.
Basically, I don't mind paying extra for a get out of jail free card if a whole swarm is offline.... I can tell the CEO we have the vendor partner engaged with a critical ticket and she can have piece of mind too. So, let's quote out the Enterprise version of Docker and evaluate the TCO of both solutions.
By calling Moby the "OSS version" you are implying that Docker EE isn't open source. Honest question... is it true that Docker EE contains proprietary code, or did you mean to say "community version"?
I probably should have written that as Community Version. I'm very uninformed when it comes to all of this and the Docker, Inc. ecosystem. Sorry about that :)
This idea isn't cynical, it's branding. The whole point of creating a brand like Moby is to trigger conversations about what level of service you're getting when you say you're using "Moby" vs. "Docker". The CTO hears they're using "Moby", which for the first time may make the CTO realize that some of the infrastructure for his business is relying on unsupported technology (or maybe he intuitively realized it but now it's obvious).
It's not a "cheap shot", and it's not for "upvotes", it's just an observation about the nature of this change being non-technical, related to messaging.
Why do we keep equating OSS to "unsupported"? Some of the OSS I use is far better supported than licensed software. Drop an issue on GitHub and it gets fixed in a few weeks.
Because without a legal contract to cover support, you don't have someone that contractually has to answer your call.
You might not care about this, and many don't. You're running the risk that the maintainers won't pack up shop and stop maintaining the project, and that you & your team will need to inherit the project.
Other way of looking at it, is that if you're a business, you always should pay for your software, even if it's open source. Because you will one way or another: through your team, or through the risk that free riding brings.
The object "Docker" has been in dissonance for quite a while now, both by the company's perspective and the consumer's perspective. I think rationalizing it as a "brand" move is a bit simplistic.
It is a FACT that individuals are unable to use the term "Docker" on anything they would like to create and share with others. This has been enforced with takedown notices and legal entities getting involved in "protecting" the Docker brand, on Docker's behalf. This, in and of itself makes sense, given Docker is a private company with a significant amount of private investment behind it, with expected returns on protecting that investment. It has used that investment well to further build the brand, as you indicate here.
However. Docker is also an idea which is one of taking a "software container" and starting it somewhere, running it for a bit, twiddling on it in a variety of ways, then moving it somewhere else where someone else can do that too, without too much operations headache as you do so. Again, it's the IDEA of this that matters, not whether it is technically true or not. The idea simply leverages the concepts of writing, deploying and running code and smears them across a the vast resources of which the Internet is comprised.
I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. Irrational beliefs are still beliefs, and sometimes it is necessary to also believe they are rational ones in order to get things done. We're all busy, and the Internet requires a lot of us to get more done in the future. People need the idea of Docker to get project's interest raised, approved, and put into production to get more things done.
This is where Docker's dissonance comes in, and does so fairly heavily handed. Docker is here to make money. They will do that at the expense of all other things, given their purpose is to preserve shareholder value first. That includes changing the idea that everyone holds about ubiquitous computing. That's not to say that shareholder value isn't tied to consumer value and completely rational, but it can also become a vicious circle very quickly when company values are prioritized over consumer values at any expense, or vice versa even.
Personally, this is why I'm not a big of traditional investments in infrastructure technologies. While I do think that traditional investments have been a great help to the growth of technology in the past, it is my belief we are going to continue to run into increasing challenges attempting to rationalize arguments for shareholder value vs. user's best interests when it comes to infrastructure. And, to make it even more challenging, I think most times the users don't realize they are trusting these offerings in an implicit way, which makes their view on matters highly irrational. That is to say, irrationality indicates additional work must be done to resolve the truths of who and what to trust. This is made difficult by applying that irrationality to the very systems on which we base trust.
I don't want to live in a reality where we are having to constantly question the trustworthiness, or irrationality, of our infrastructure.
I don't have a great suggestion for how to fix these types of issues other than proposing a radical change in infrastructure business models. I do have a suggestion on how to do that, but it will make it completely irrational for traditional investors to consider, which would limit the adoption of it, even if it got going. A catch 22, if there ever was one.
"I've seen the gleam in people's eyes when they talk about a ubiquitous computing infrastructure, of which it will run their code, without question, and never, ever breaks. "
This seems to be a much higher level construct , like PaaS or Lambda, than what Docker provides.
Docker was more of a bottom-up wake up call to those upper layers that lower layer technology usability still matters.
I never said otherwise. Again, the idea people hold about a technology, with a given tag, is moving in the direction of what they expect as users of said infrastructure. Please note that I did indicate this was an irrational belief. Whether or not Docker actually does this thing people understand it to be is another argument entirely.
It probably depends on each of our anecdotal experiences. I've worked with and met some higher ups in companies and government organizations that would actually react like this and I met some that were very well educated. Unfortunately I've worked with far more of the former than the latter.
So to me it seems fair but depending on your experience I could see it as a cheap shot for upvotes as well.
I've never met senior people who couldn't understand the naming difference between the open source version of a thing and the enterprise-branded version.
Here is an old saying: "Nobody ever got fired for buying IBM" - neatly illustrating the issue. I have met _many_ senior people that don't understand these naming differences. They tend to be the bosses of the CEO and CTO's
When you tell your boss you adopted moby, he's like "WTF is that?!".
If you were already migrating to Docker, now you have to explain that the project name changed overnight without explanation, and it's hurting your credibility pretty bad. It's also gonna bring a lot of confusion onto everyone for a very long time.
Use the tried and true engineer response. Docker does many things because it has to be all things to all people. Docker is composed entirely from Moby, we're only composing the parts that matter to our organization. It'll be faster, use less resources. Even better, it reduces our attack surface because we're removing all that stuff less experienced teams need to muddle through their deployments.
The three points seem to be, cheaper, more secure, and the other guys are dumb.
If it was not for "reinventing the wheel" we'd all be coding in cobol or Fortean against IBM supplied mainframes.
In other words - because they can and should (and can afford to and not be hooked up to some third party vendor milking them for the rest of their companies existence).
Why sell your soul to Tableau when you can leverage your large pool of engineering talent to create something that only requires investing once, rather than large recurring license fees forever?
In my opinion Superset actually fills a niche that was open for far too long.
Eh, that line is fuzzier than it looks from a distance.
Product managers are responsible for dealing with roadmaps and timelines. Managing expectations is necessarily part of that job.
Add in agile practices where the PM may also be a PO directly managing a backlog and the line gets fuzzier still.
It's part of what makes that job so challenging, as you have to wear so many hats. It also makes the job very difficult to define, and I think, makes the question itself a little tough, since a PM in one org might be a very different role from a PM in another.
all fortune 500 companies I worked on that had only PM doing both jobs it went like:
PM promises some project worked out with a designer that only knows the how to wireframe generic screens, both lack understanding of the product and tech. usually because the PM just moved from another place 3 months ago.
PM show up every day at standup and fail to understand the current priorities, push the new project, the enginners see how pointless but easier than real priorities it is. Then remember it is a fortune 500 company so the easier the better. Everyone works on the useless project, try to explain the product to the PM but he will have none of that, after all the wireframes are done! Agile is actually used as an excuse "don't worry, we will iterate later". The PM will now disappear until close to the deadline when you will get constant meeting invites to assess progress, which will never be the standup. Project goes live shoved into actual product and it is a complete failure but everyone mentions it on their accomplishments so management starts to see it as a success. Everyone involved gets a promotion. PM moves over to help troubled team. Some engineers stay and are tasked with maintenance. A year later execs see the numbers and blame the current team, labels them as a troubled team so they get a new PM (remember they had none because the other one left to help another team labeled troubled).
Well, on the bright side, all you aspiring PMs out there, take note: see how low the bar is??
Speaking as a PM/PO that, I hope, doesn't suck, if you simply take the time to:
1. Understand the market.
2. Understand the product.
3. Understand the user.
4. Actively engage with and converse with developers and negotiate requirements rather than acting as a lofty dictator, and listen when the engineers raise concerns.
5. Be engaged in the process so the product can truly evolve as market and technical requirements are uncovered.
6. Own failures.
7. Share successes.
I'm sure I've left lots off the list, but it's pretty basic stuff (which, I suppose, all starts from the same basic place: humility)...
Funny how a Slack group is used for discussions. No offense to the lovely people at Slack but they fall into the category of "private, short-lived, growth-oriented companies", no?
Thank you! This makes perfect sense: "A huge percentage of online advertisements are never seen by humans. They are viewed by bots–automated scripts that are opening web pages in a browser and pretending to be a human. Advertising scammers set up web pages, embed advertisements on those pages, and then pay for bot traffic to come and view those advertisements."
