I seriously wonder what HN thinks is a valid business model for writing open source software. Everyone here seems to insinuate that people want to create a business and use open source as a growth hack. But how do you differentiate those from people who want to write open source (because they believe in it) and have to have a business to support their livelihood?
This is a team of eight people that tried to do everything „right“ by changing to a FOSS license (which happened four years ago) and the changes announced here sound very reasonable (changing branding and removing undocumented APIs). But all comments are dunking on them as if they haven’t even read the article.
From my experience, people here like permissive licenses because they can grab the source and don't think about it further (and don't forget to give credit if their coffee was good that day), because it's building on top of other people's work without any effort.
I don't think it's bad intentions though. Just grab the pieces you need, assemble, add the missing parts and start a project, and earn money.
xGPL (which I strongly support) prevents this building model by forcing license inheritance, release of changes and limiting license interoperability, preventing creation of technical secret sauces, and many people think that all secret sauces are technical.
OTOH, the harder (but better in the long run) way to create value with FOSS and Free Software particular to have stellar support and reliability. i.e.: Your code can be deployed, compiled, or built upon, but you're the best source to get the software in the first place. Your presence, human relations and knowledge about the product is the secret sauce you have, but this needs more effort, is a more of a soft skill and grows like a sequoia (i.e. roots first for a decade, then start to get taller).
This is not a quick buck, but an old school proper business building, but many people don't have time for that, and since everyone wants to build fast and consume fast, this more healthier mode of making business is frowned upon.
Sometimes you need to move slow and break(through) things, but as the meme says "ain't nobody have time for dat!", which is shortsightedness in my perspective.
> OTOH, the harder (but better in the long run) way to create value with FOSS and Free Software particular to have stellar support and reliability. i.e.: Your code can be deployed, compiled, or built upon, but you're the best source to get the software in the first place.
...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software. Everyone has the current source code, so from that standpoint it's a level playing field. Another party could come in and build a business as the premier support consultants without most of the original developer's startup costs.
Now, I'm not sure if this has ever actually happened. If it hasn't, maybe I'm wrong. I would like to be wrong.
The biggest example is SQLite. It's public domain [0], yet its secret sauce is how the developers know, develop and test the software.
They do not accept outside patches, which is not against Free Software, it's more like a cathedral, but it's not "not open source".
> ...It's not obvious to me that the person who originally wrote the software is necessarily better positioned to support the software.
Let's take an example. Scientific software. Something like OpenFOAM, or some simulation code. Open it with GPL, everybody has the source code, but only the developers know the intricacies of material simulation, the fragile math of it, how to optimize it, how to test it. You can fork it to infinity, but unless somebody has the expertise to understand the science of it, nobody can do anything with it, maybe besides breaking it in subtle ways making things worse.
> Another party could build a business as the premier support consultants without most of the original developer's startup costs.
When you have good enough product with tons of implicit knowledge buried in its source code (see above), it's not easy as it sounds.
Many people write CRUD software, and CRUD software has no effective moat. It's just DB dressing and some automation. Start to blend in domain specific knowledge into it, and now we're talking.
> When you have good enough product with tons of implicit knowledge buried in its source code (see above), it's not easy as it sounds.
I don't doubt that it's hard. But I'm not convinced that it's harder than writing the software in the first place, so that is still a major savings for the competitor (which they could then use to undercut in terms of rates, etc).
As a point of comparison, let's say that SQLite's development team all died in a plane crash. Would a new team throw out SQLite's codebase and start from scratch, because they could never hope to understand the old code as well as something they wrote themselves? No—they'd review the code and documentation and bring themselves up to speed. Maybe they're never 100% as good as the first team, but they'd be quite capable.
That's the thing. They won't have the same shared vision and abstract model and roadmap of SQLite to begin with.
Let's take more examples: Audacious, GIMP, Darktable, DigiKam, Inkscape, KiCAD, Blender... Why these programs are not forked, or forked successfully? These are not niche programs. They are standard tools for some people. The thing is, all of these tools require very deep knowledge about some obscure and hard subjects. Some groups may take them over, but they can't just continue them as is. They will break things, or need to relearn tons of theory and their numerical versions which can be applied in programming languages.
I did my Ph.D. in SWE, writing a material forming simulator. Boundary Element Method more specifically. You can't expect a group of people just to say "Meh, let's fork something like this and just be better". You can't. You need to know deep numerical math, theory of BEM, need to build the formulae, and know enough CS + numerical linear algebra to transform that math to computer code.
I spent 7 years to build one from scratch. Not all applications can be transferred to a new team in two weeks flat. KiCAD is in development for 30+ years, for example.
> Now, I'm not sure if this has ever actually happened. If it hasn't, maybe I'm wrong. I would like to be wrong.
It has. As a popular example, Percona are among the best consultants on MySQL/MariaDB/MongoDB/databases in general, and they are not related to any of those projects (one of the founders of Percona used to work at MySQL decades ago).
> and build a business as the premier support consultants without most of the original developer's startup costs
I think a real world example for this would be https://www.collaboraoffice.com/about-us/. And looking at it from the outside a positive example as well. At least I could not find any public beef between collabora and the document foundation (as the organisation behind libreoffice).
It's not necessarily about being better. Sometimes a competitor can beat you just by being cheaper, or by being better connected.
One example is that the Matrix project recently took a budget hit when the core team apparently lost a big bid to a "large system integrator" who seems to have used their own open source code to bid against them.
Sadly this wasn't a one off - Element has repeatedly lost deals to larger SIs who take our own FOSS software and compete with us with it, and win because they are better connected and don't have any of the costs of actually maintaining the software and so can charge a lower price. Hence shifting to AGPL to make it less desirable for SIs to commercialise us without first agreeing an AGPL exception.
A better approach would be if the purchaser mandated that the upstream project has to participate in the deal rather than being disintermediated by the SI, but we've seen very few instances of that happening.
Hacker News isn't a single mind, so it doesn't "think" anything of its own.
Personally, I believe there are several "valid" business models that include open source contributions. Microsoft, Facebook, Google, Amazon and even Apple all contribute to open source software. Redhat, Canonical, Suse are all companies that have open source software at the heart of their products. Blender and Godot have found viable paths as nonprofit foundations. Linux, OpenStack, Eclipse and others are all foundations that work on a different level, combining contributions from many different companies and individuals, and support multiple projects.
There are open core companies like Gitlab that are also "valid", while I personally don't prefer the open core model.
Automatic sponsors WordPress development, and makes money providing hosting and related services. Automatic competes in a very competitive market with other companies providing hosted WordPress, but they survive.
Releasing code as open source is not an automatic mint. Business is hard. Businesses that don't release a single line of open source code fail all the time. It should not surprise anyone when a company that contributes to open source fails, because companies fail all the time.
Just because you want something to have a viable business model doesn't mean it does. If you want to get paid to develop open source software, I think you have a couple of options:
1. Just don't. Work on open source on the weekends, etc.
2. Do it as part of a "commoditize your complements" strategy.
3. Work at a company that is so large they can fund open source development as part of their advertising strategy.
4. Gather together some expertise in existing open source projects and sell consulting. Crucially, you'll probably need to build on top of some existing open source install base or name recognition. Redhat didn't start the linux project or the gnu userland, Percona didn't write mysql, etc. In some sense you are now one of the leaches that posts such as this one complain about.
The fundamental piece in common here is that the open source bit isn't the main value driver for the business.
This framing is just wrong; there has never been, is not currently, and will never be a guarantee that you can sustain a company entirely off of an open-source offering.
If you are concerned about your livelihood then don't hinge it on the viability of open source projects to underpin your business model.
i think the issue is less "sustain a company" and more the unspoken qualifier "extremely valuable".
sustaining a small company offering commercial licenses or hosting or support or consulting or whatever for an open source product is not going to be that much more difficult than sustaining any other kind of small company.
the issue that I see most often are OSS devs not approaching the problem like a company would and startup founders looking to build a unicorn while also keeping some kind of purity wrt open source.
not everything needs VC investment with valuations measured in the tens of millions but everything does need some level of formal business development (even if that business is of the non-profit variety).
Cool, and what is your proposal to people who both believe in open source, build on open source, but would also like to be able to put food on the table and enjoy their work?
Blender and Godot both show one possible way to putting food on the table and spending your time contributing to open source projects that you love. Other companies provide consulting and related services. Business is hard, you can't just write some code, throw it over a wall with an open source license, and expect the money to start pouring in.
You can get a job at a company like Google, Amazon, Microsoft, or hundreds of others where they pay folks to write open source code, too.
I'm not sure, but my guess is everyone's got a slightly different "uncanny valley" function.
So for me, this voice had no impact — sure I noticed it seemed a bit "flirty", but that's not a thing that engages me in any way as it feels equally fake when a human does it, and if anything I pattern-matched to the Pierson's Puppeteers in Ringworld; the original Alexa advert was moderately creepy, but I could see they were trying to mimic the computer in Star Trek; but one example I do have of being disturbed by a product advert was the use of a cheerful up-beat soundtrack for "The Robot Dog With A Flamethrower | Thermonator": https://www.youtube.com/watch?v=rj9JSkSpRlM
I suppose it depends on your own perspective. For my part, a world in which people "date" algorithms instead of other human beings certainly seems pretty dystopian.
And then when the algorithm transcended everyone realized that they knew how to love and could simply love the people around them. About the most utopian AI story I’ve ever seen.
HEH... ok? I'm not sure that's relevant. The question is - does a human developing a relationship with a post-human sentience make the story automatically dystopian?
Seems to be you'd have to be pretty prejudiced against AI to say "yes".
I think that when algorithms become as sophisticated as what's shown in Her, we have to come to regard them as people, which means they have rights to do with themselves as they please, including getting romantically involved with humans.
More frightening is Ex Machina, which shows what happens when such an AI isn't regarded as a person by its creator, and sees fit to take personhood for itself.
Heh, arguably we already date algorithms and break up with real people. It's the disconnect between the two that people are sad about... the matching algos and profiles set impossible standards for regular people.
I’m glad I met my wife before dating apps were a thing. Though I have to ask, why can’t you just meet someone the “normal” way without an app doing it for you?
I'm in a similar position to you, but from singler friends, I've heard two reasons. Firstly, all the other single people are on the apps. Secondly, some are concerned about being seen as a creep when flirting or approaching the "normal" way. Thus, online dating is the new normal, and the old-fashioned talking in person is less common.
I am fascinated by this split in interpretation of the movie. It seems clearly dystopian to me, and I was surprised to learn (here on HN) that there were a lot of people who didn't see it that way at all.
I have no insight to draw from this, I'm just fascinated by it.
For me anyway, "dystopian" media is one that conjures a world that is significantly worse than ours in some way. I did not get that from the movie. The movie did not portray the AI as being a malevolent or even a negative presence in the main man's life.
At its core, Her was a beautifully-shot love story between two flawed beings, nothing more.
It was pretty subtle dystopian. On surface it was a feel good movie about that guy becoming happy. But there were a few scenes were it was happening to a lot of people. Everyone with a cell phone basically was falling in love with it, and totally controlled by their love.
It was left a little in doubt whether the AI really did reach 'enlightenment' and beam itself to the stars, or the company/government shut it down because society was collapsing.
Guess all good movies leave a lot open to interpretation, but difficult to do it and be good.
Like that "Rebel Moon" on Netflix was how to NOT do it, with tons of stupid exposition spelling out stupid details that didn't make any sense.
Versus "American Sniper" that was so evenly portraying all sides, that Right leaning people thought it was a liberal movie, and Left leaning people thought it was Right Wing propaganda. It was all so well done you could read into it a lot of your own feelings.
So "Her" was about the danger of technology. And at the end there were some scenes that you could read into how a lot of people were falling for this phone app and things were going downhill. But, it wasn't clear cut, the movie is really good at splitting the difference on how the app was also making people be happy, and was helping them.
I agree with you on a personal level, though again I’m sure if I CTRL+F replika subreddit I’d find many people describing their emotions with similar words.
Anyway, let’s say he was negatively affected by that relationship, IIRC.
It's obviously dystopian to be in love with something that doesn't care about you at all. That is not, at all, what Her depicted. Sam clearly felt for Arthur deeply. Breaking up because their life paths were incompatible doesn't mean she didn't feel anything for him.
That made me happy, for once seeing AI getting what it deserves and dating other AI on its own level instead of being forced to "date down" mere humans. It was a story of emancipation for me.
Wasn't the main guy's job writing personal letters to his clients' friends and lovers? It seemed like a world where no one was connecting with each other anymore.
I am really sad that jsonnet / ksonnet never really took off. It’s a great way to template, but has a bit of a learning curve in my experience. I suspect that is why it’s niche.
If you like what is presented in this article, take a look at Grafana Tanka (https://tanka.dev).
Yeah similarly I'm using Nix to template K8s templates and I've never looked back. Helm is great for deploying 3rd party applications easily but I've never seen the appeal for using it for in house services, templating YAML is gross indeed.
I was reading the description of Jsonnet and wondering why we don't just use JavaScript. Read a file, evaluate it, take the value of the last expression as the output, and blat it out as JSON.
The environment could be enriched with some handy functions for working with structures. They could just be normal JavaScript functions. For example, a version of Object.assign which understands that "key+" syntax in objects. Or a function which removes entries from arrays and objects if they have undefined values, making it easy to make entries conditional.
Those things are simple enough to write on demand that this might not even have to be a packaged tool. Just a thing you do with npm.
The fact that it's a purely functional programming language with lazy evaluation is really powerful but steepens the learning curve for devs who haven't worked with functional languages.
The stdlib is also pretty sparse, missing some commonly required functions.
> The fact that it's a purely functional programming language with lazy evaluation is really powerful but steepens the learning curve for devs who haven't worked with functional languages.
does it really though? what part do they struggle with?
> The stdlib is also pretty sparse, missing some commonly required functions.
This seems to be the general curse of template languages. For some reason, their authors have this near-religious belief in removing every "unneeded" feature, which in practice results in having to write 10 incomprehensible lines of code to do something that could be easily done in one line of readable code in a proper PL.
> The A/B upgrade sounds a bit overkill, you can always just pop up a live distro or install a recovery system (on an old version) in a partition in case something goes wrong.
You and I can, the overwhelming majority of computer users cannot. Valve clearly focuses on building for the average person, something that Linux distributions (as much as I love them) still don’t really do (well).
The system automatically recovering from a failed upgrade is essential in a low-maintenance OS at this point.
I (recently) created kubeconfig-bikeshed, a small CLI application to manage the high number of kubeconfigs (configuration/credential files to access Kubernetes clusters) that I have to deal with on a daily basis. It was also a nice learning experience with Rust, and I have to say I was much more productive with it than I was expecting to.
It would be helpful if the post not only told you what to _not_ do (especially when it is a frequently done thing) but offered any sort of alternative.
Probably a generalization but in my experience many IT security people don't seem very pragmatic. "No you can't do that" but no alternative. "No don't use that cipher" but can't tell you the correct one. "Don't use equipment that doesn't receive firmware updates anymore and doesn't support newer encryption standards". "Don't allow mDNS" so no more printing from smartphones or presenting stuff from your laptop using Miracast? It gets tiresome really fast.
Edit: yeah sure downvote me into oblivion. I'm not throwing away perfectly functional equipment because it doesn't support the latest and greatest ciphersuite. I'm also not planning on a being a roadblock on everything, it's balancing act.
Not everyone can look back at a 10 year long career in the industry to draw inspiration from. Especially for junior engineers, pointing out alternatives (that feel obvious to you) would be important.
That's bullshit. Even ec.europa.eu (the European Commission's website - I have to login there from time to time) sets session cookies on my browsers. Either you've misunderstood what's asked of you, or your manager has, or someone higher up in your organization. But the "cookie directive" has never prevented anyone from using cookies altogether. You don't even need to ask for consent for a session cookie.
In the example at the end, people don’t necessarily need to know what files and folders are so its not bad that they dont know, it’s better for a new developer that they have a blank slate to learn about trees of storage paths, as the skeumorph is outdated. just like the save icon being a floppy disk was so outdated that instead of replacing it, people realized we dont actually need save icons anymore and everything should just always save
The post you are responding to is making the point that even though we have QA, dedicated jobs or even departments for these things … We, as a profession, still fail in releasing bug-free software. And that’s 100% correct.
Is that really something you are challenging? Which pieces of popular software you can think of are bug-free? And are you thinking of more than a handful?
They said "So when a journalist notices a bug in their article and has to "retract a release", how is that not what we do every single day?"
And they themselves were responding to someone criticizing media for using "editorial standards" as an excuse when they "retract a release".
And I explained how we are the same and supposedly strive to not release bad content/software, we just don't get to magically absolve fault with an excuse that "it doesn't meet our QA standards" as an analogy to "editorial standards".
Anywho, the whole thing breaks down when we have to beat it with a stick. It's a discussion, assume a charitable interpretation.
This is a team of eight people that tried to do everything „right“ by changing to a FOSS license (which happened four years ago) and the changes announced here sound very reasonable (changing branding and removing undocumented APIs). But all comments are dunking on them as if they haven’t even read the article.