A softbox could be used as a key light, and often is, but it’s classically more appropriate to use as a fill light.
Soft light (which a softbox ideally creates) is defined by diffuse shadows. Perfectly soft light would cast no visible shadows.
An important creative job of the key light, which is called such because it’s the main source of illumination in a scene, is to create a sense of depth by casting shadows onto the 3D objects, giving our brain cues on how to translate them from 2D space into an accurate mental image. Usually harder lights (meaning those with sharper, more defined shadows) are used for the key to create this depth, then the fill light, well, fills in these shadows with additional light to walk them back, which is why soft lights are appropriate there.
As with all creative rules, exceptions abound. Maybe you could make a virtual lighting portrait studio, have sharp white light on one part of the screen, then some sort of gray gradient on the other to fill in some shadow. Unfortunately, that would be most effective if they had a big curved screen and they were willing to sit very near to it :)
What are the risks of doing this? I would love to ramp up the nits for outside work, but presumably it's been limited to 500 nits for SDR for a reason.
> 1. If most of the screen is not full bright white, (e.g. white text on dark background), then LEDs will have plenty of time to cool down
Note that the display is not an OLED display, but a regular IPS LCD with local dimming zones for the backlight[1]. Thus only the dimming zones not covered by white text would get to cool off.
This also points to another downside of pushing up the nits: it will likely increase the bleed-through of the backlight, driving up the black level especially in white-text-on-black scenarios.
They added this 500 nits limitation to always leave room for HDR, so that SDR and HDR "coexist" properly. But it looks terrible imo I think they failed on that front.
Also they want HDR to be a selling point. Not many phones take HDR videos and images. "It goes brighter" is what makes HDR pop.
What makes it look terrible? The majority of consumer displays max out at 300-400 nits. This is the whole point of HDR, webpages are not designed with “sunlight-white” intended for the background.
I don't know what the cause is (the iPhone camera or the display methodology), but whenever I watch an HDR video shot on my iPhone on the MacBook Pro XDR display it looks really unnatural and bad. HDR demo YouTube videos in full screen look fine, so maybe it's the iPhone, or it's the integration with the SDR UI, not sure.
This is not the right way to think about it. What nits are books designed for? Do books look bad when you read next to a window despite being well past 1,600 nits?
The comfortable amount of nits is entirely dependent on ambient lighting conditions.
Next to a window, 1600 nits can look dim.
What Apple is doing now looks terrible because SDR and HDR do not coexist well at all. Any HDR video even ones that you wouldn't think would be "bright", blow up the screen while your SDR content next to it is now hard to read. HDR and SDR should have a comparable average brightness level with only "highlights" going "brighter than bright", but that's not what they do, they make the entire video brighter. People want uniform brightness. If I want my entire screen to go bright, I can set the damn brightness myself.
> HDR and SDR should have a comparable average brightness level with only "highlights" going "brighter than bright"
This is exactly how it works. When I open a video and switch between 500 nits and 1600 nits in Display Preferences, everything looks exactly the same, except for the highlights in the video. Of course outdoors daylight scenes will have a higher average brightness.
There is no point to 'high dynamic range' if a bright sky is the same brightness as a sheet of paper, or your website background; it's supposed to represent real-life brightness and contrast in photography & video, and there is no reason for your graphical interfaces to reach those light levels, i.e. Slack's white background should not be close in brightness to a cloudy sky. If they didn't "limit" non-HDR content to 500 nits (again, already above the average monitor), how would it be possible to have HDR at all?
I don't see how the content could become harder to read, when the light output is exactly the same. Your description reminds me of a shitty Benq 'HDR400' monitor, which would artificially limit the light output for non-HDR content making it gray and dull. That is not the case with the mini-led macs or better HDR monitors.
Some examples of decent HDR - these look fine next to a browser or anything else on a MBP 14", and also in Windows with HDR on:
Not in my experience. I've seen iPhone videos that were entirely in the HDR range despite being indoor scenes in ambient lighting lit from a single window.
> There is no reason for your graphical interfaces to reach those light levels,
Again, I'm using Lunar right now and I find it useful sitting in next to my window. Not sure how that can be considered "no reason". It's literally useful to me right now as I use it.
> how would it be possible to have HDR at all?
It doesn't have to be possible! I don't use HDR. I don't care that theoretically HDR content would clip. It's not on my screen.
I'd rather HDR just use the same brightness range as SDR. Let me choose myself where HDR maps compared to SDR. I really do not want HDR as it is implemented today.
> I don't see how the content could become harder to read,
My eyes adjust to the HDR average picture level, and then SDR appears too dim.
Some of these problems stem from bad HDR tone mapping. But regardless, I want to control where SDR white maps because my workspace is bright. And I enjoy well lit rooms.
I have a Samsung monitor that does this too, but it has an override in its menus. In normal mode it’s stupidly dim. HDR looks like shit, so I just want SDR with proper brightness.
It always looks washed out. Is it perhaps only for certain games or image/video editors that support it properly? Or does the support overall just suck?
Wow, this app is great. It unlocked the audio setting on my external LG display (which im running my speakers through), and lets me control with the keyboard keys! Thanks for making this.
I'm trying to use "sub-zero" dimming with a 2021 mbp but can't figure out how to use it.
EDIT: for anyone confused, it's because XDR and the sub-zero dimming only works in the drop down from the menu bar but NOT in the main windows of the app.. Very confusing.
Then just lower the brightness to 0, either with the slider or the brightness keys. Another red slider will appear for the sub-zero brightness and brightness keys will control that slider now.
EDIT: I saw your edit now. I'm trying not to add more elements in the Preferences window as it's already too complex. The Preferences window is supposed to only be used when you have to change some more persistent settings.
Sub-zero dimming is easier to use with the brightness keys.
That makes sense. I think the reason I was confused is that when you first open the app, it shows the preference windows, so I tried to set the brightness below 0 in that window. It didn't work, so I checked Allow brightness to reach zero. I then tried the keys and it didn't work due to me having checked that option. I then unchecked it while trying to figure it out... And eventually saw the screenshot on your site where the user is interacting with the icon in the menu bar) which is how I got it working.
If this works properly for a code editor I may have to reconsider buying a MacBook Pro for coding in the garden. Not looking forward to switch from Linux to macOS but the hardware is pretty good.
Congrats on cracking whatever privateframework to make this work!
I went from macbook to a raised, close-face Linux tablet for my outdoor computing setup (and have been thinking about hi brightness since the MSI Creator 17 and iPad pro 12" came out last year).
There's the book mira 13" (and 25") and dasung paperlike 13", which is much better than earlier years but even then they have their classic eink quirks (resolution isn't going to be as good as a hiDPI display, they also need some input power to do eink at high refresh modes, etc.). Plus it's yet another thing to carry.
I've had a 'good enough' experience so far with the raised tablet setup outdoors and an extra battery.
There has to be dozens of us. I also work in the Denver Botanic Gardens, so nice.
As an aside, does anyone know what's up with the linguistic difference between Botanic and Botanical -- Gardens --... are both correct? When speaking, all my friends say "botanical gardens" but every gardens I've been to says "botanic gardens" on the placard.
You can finally go outside and work on your laptop in the bright sunlight without squinting! You probably don't do this often, but it's nice to have, right?
> You can finally go outside and work on your laptop in the bright sunlight without squinting! You probably don't do this often, but it's nice to have, right
Dear god, is this what laptop makers think too? I want a laptop to use in the sun outside. I actively look for a laptop that does that, but they're either super expensive and/or super ugly.
Well it’s definitely not the advertised use case. The promo videos are mostly made with studio rooms in mind. I’ve yet to see a laptop advertisement where someone is working outside in sunlight.
My bad - I noticed that the screen becomes brighter than it is possible to manually set it to when it's in harsh sunlight, so I assumed that this was a result of it increasing the SDR brightness limit past 500 nits, I didn't know that such conditions were required merely to push it to 500 nits. Thanks for the info!
Is it bad for your eyes? How does looking at an extra bright screen compare to looking at white paper in sunlight? I can imagine it is no problem to eyes adapted to the sun, but maybe there is a difference between emitted light and reflected light?
And do you think it is safe to the screen? I heard that the screen will throttle itself at low-level when overheating anyway. (Edit: saw you answered it somewhere else in the thread!)
Really excited to do a bit of coding in the garden now, but I'm worried for my eyes and my new MBP :-D
In terms of the amount of light going into your eyes, my intuition says that you’re getting more nits from a white sheet of paper than from a dark screen with white text (in direct sunlight)
But staring into that light for a long time will tire your eyes no matter if it’s reflected or projected.
Any potential dangers with using it on a Pro Display XDR? Wouldn’t want to ruin that screen, but I do have a very sun-lit room and one of the reasons I got the monitor was it’s sustained 1k nit brightness (and only afterwards realised that it tops out at 500 nits and anything above is XDR only…) definitely going to try this though!
Here's a photo of my XDR display with a pure white rectangle in Figma next to white content in an HDR video, with the display set to the 1600 nits mode:
Many. For a lot of laptop models, you can remove the bezel around the display and unscrew the display from the topcase. That allows you to upgrade/replace panels as-needed. Apple notoriously builds their displays directly into the topcase, which means that when your display malfunctions, or the screen cracks, you generally have to replace the entire top component instead of just the broken part. That's why anything "breaking above the hinge" on a Macbook will run you $600+ to fix no matter who you're paying to replace it.
Apple replaced the display on my 2017 MacBook Pro under warranty too (because the backlight died). They're definitely replaceable, just not (intended to be) user-replaceable.
It is user replaceable. A guy came to my house with the new screen and a screwdriver set and swapped it out right there on my desk. Even left an extra bezel behind because they like to warp after months of opening and closing the lid, causing even more backlight bleed.
My Precision is incredibly upgradable and user serviceable (I've swapped my wifi module, ram, m.2s, and serviced the fans myself), but it has a horrible screen (because of severe backlight bleed), trackpad, weighs nearly 10 pounds, and has a battery life of less than 30 minutes after 3 years. Oh, and let's not talk about the thermals...
I’ll open source this feature and do a write up this week. But as a hint, it involves some internal SkyLight.framework and Core Brightness APIs to ramp up the headroom slowly.
I've noticed a lot of Apple software pretends to be open-source (like this one: "Lunar is also open-source so you can check that for yourself: Github - alin23/Lunar
"), when they really aren't. They're - at best - open core: https://en.wikipedia.org/wiki/Open-core_model
For example, I quote from the Lunar GitHub page:
> I'm pausing contributions for the moment as Lunar has paid features and isn't compilable because of missing parts of the source code (Pro features code is encrypted).
> Lunar can't be built from this repo yet as the source code for the paid features is hidden. I will try to post stubs for those paid features to at least make it compilable in an only-free-features form.
So right now I couldn't modify and/or redistribute Lunar as I see fit. It is not open source.
And even if the Lunar repository is updated so that it at least compiles the free version, then what? Then it would fit the strictest definitions of open-source (you are free to modify and redistribute), but would miss the community aspect completely due to misaligned incentives. I could add a great feature, but my pull request would be denied if it overlaps a paid feature.
You could fork Lunar at that point and make all the traditionally paid features for free and accept pull requests simply based on merit. But at that point you would be open-source, and not open-core anymore, and the concept of a paid version would simply go away. I don't really see open-core actually working in any way other than an attempt to leech contributions from the open-source community without playing by its rules.
I disagree, it is Open Source, just not all of it.
To me Open Source means the source code has been published under a licence that allows me to make changes and to some extent redistribute it. A good indicator is if the licence is approved by OSI (https://opensource.org/licenses)
It does not mean:
- they take contributions
- there is a “community”
- there is support
- that it is “developed in the open”
- that there is a public bug/issue tracker
- that they provide you with details in how to compile or run it
- there is any documentation
- that the source code is in a complete state and wouldn’t need changes to get it to run
If it ticked those boxes it’s an “Open Source Community Project”.
If the source code (or at least a significant portion of it) is available under a OSI approved license then it’s Open Source. If not all the source is available they should probably say it’s “partially Open Source” to be better citizens.
I believe the FSF would even mostly agree with that list for their definition of “free software”, however they have stronger thoughts about the licences and restrictions they apply.
> If the source code (or at least a significant portion of it) is available under a OSI approved license then it’s Open Source.
It's the part in brackets I disagree with... If a significant portion of a piece of software is available under an OSI approved license, then a significant portion of it is open source.
It's still wrong to call the product open source, because "the product" includes integral parts that are not open source.
If you can't build it from source, then it doesn't qualify as open-source to me. If they eventually decide to make the "free" version compile, then I'll be fine with them calling it open source (even if paid features aren't available). However, until then, a more apt description seems like "an open component of a proprietary application"
I've kept that around, it's still compilable, but probably not that useful.
When making Lunar paid in v4, I didn't want to remove the possibility of sharing knowledge, so I kept the non-paid parts open-source.
This allowed other apps like MonitorControl [1] and DisplayBuddy [2] to port some Lunar features (like DDC on M1) to their own code. So I'd say it's still useful enough.
Just to clarify, I am okay with paid software existing. It is even better if you share (parts of) the source code to the community in a permissive license. But unless your incentives are aligned with community, I would be crystal-clear and not advertise it as open-source.
Your incentives aren't aligned with the community. Should a free, open-source alternative to Lunar exist with all its features, your sales would go down. It is in your best interest to:
1. Create the best possible product that works the fastest, smoothest, without bugs, etc.
2. Create a minimal viable free product maximizing the amount of new trial users for Lunar.
3. Maximize the difference between the free and premium product to convert the most users from #2.
Open source contributors shares incentive #1 with you. They don't share incentive #2, but there's no conflict here. But incentive #3 directly clashes with those of an open source contributor if only the free product is open source.
I want to assume good intentions here, because the malicious interpretation would be that one wants to take advantage of the open source community by getting free work done on incentive #1 while rejecting anything that would cross incentive #3.
So what is your goal? You obviously want to make money - we all do. What else? Is your goal to give to the open-source community for similar applications that wouldn't directly compete with you? It's noble, but risky, as you can't enforce that. If your goal is to conduct a 'business transaction' with the open-source community: "access to my source code in exchange for potential contributions under conditions w.r.t. incentive #3", that's fine too. But that is not open-source.
If you simply publish the source code explicitly stating that parts of the source code of Lunar is available under a permissive license, that you only merge contributions that fix bugs or add pre-approved features, but otherwise people are free to do with it what they want, I don't have a problem with it. But calling it open-source is misleading in my opinion.
The goal for having the non-paid parts open source, is to share knowledge.
I have to reverse engineer a lot of macOS internals and some hardware too to make some features possible. I don’t want to keep that for myself.
This XDR thing makes an exception because it required a lot more RE work than I expected I’d like to get some publicity for it before open-sourcing and writing it up.
I don’t think I can take advantage of the open source community here. The OSS community has largely chosen MonitorControl since it is fully open source, free and accepts contributions.
I couldn’t have started Lunar without the open source ddcctl [0] project, and I want to give back as much as I can without jeopardizing sales and having to go back to a 9-to-5 job.
That is all fair. Again, I don't have a problem with you, your project or the code you shared at all. I think it looks fantastic, and I applaud sharing the reverse engineering efforts. I only take issue with the choice of words, in calling Lunar open-source.
It could be specified that only the free version is open source. You may also experiment with open sourcing some paid features too, possibly with some delay after the release if you're concerned about forks eating into your profit.
I think the fear of forks is often overblown in this context, especially with consumer facing software. You have a huge advantage in terms of expertise and an established user base, and people will tend to pick your project over a fork, even if you open source everything and publish a paid package from the open source code. Those who are usually willing to pay for software will buy it for the convenience of not having to fiddle with the source code after every update, and to support the development of the project.
Plenty of us think open source means the source is an open book to be read, not a right to take and republish.
There’s a libre or free software mindset that tends to insist “open” source should mean free things as well, but many of us, including supporters of free software, disagree, saying these are two separate concepts.
Free Software may require open source, but to keep terminology tidy, open source should not by definition drag in any requirements of free. For example, Free Software Foundation points out beneficiaries of free software have a right but not an obligation to give a copy of the software source.
Here the Free Software Foundation agrees that open source and free are not the same, and defines open source more the way you thought it meant:
> The FSF also notes that "Open Source" has exactly one specific meaning in common English, namely that "you can look at the source code."
> It states that while the term "Free Software" can lead to two different interpretations, at least one of them is consistent with the intended meaning unlike the term "Open Source". The loan adjective "libre" is often used to avoid the ambiguity of the word "free" in English language, and the ambiguity with the older usage of "free software" as public-domain software.
All that said, the term open source does come with the preconception of not just study as you mention, but generally some ability to adapt for self and often distribute further, which of course doesn’t work if it doesn’t compile.
> Plenty of us think open source means the source is an open book to be read, not a right to take and republish.
No. The term “Open Source” was defined to have its meaning at the time of its creation by the OSI. You have no right to redefine it to suit your wishes or preferences. The FSF does not agree with your definition, contrary to what you imply by selectively quoting them. Your quote comes from a text where FSF argues that the selection by the OSI of “Open Source” as a term was a bad choice, since it can be misinterpreted as simply “you can look at the source code”. This text should then obviously not be understood to be an official statement about what FSF believes “Open Source” to actually mean.
Also, neither “Open Source” nor “Free Software” imply any right to “take”, as you put it. Both terms are instead about what someone already in possession of the code is allowed to do with that code.
Your world view may be sensible and internally consistent, but it does not appear to entirely match what either the FSF or the OSI says.
Plenty of us disagree with your flat “No” meaning it’s neither flat nor even no. Not because we redefined OSS, but because it is colloquially defined.
As regards FSF, I feel their point and mine is the terminology turned out not clear, as the pure definition you cite failed to stick. Language evolves, usage evolves, definitions are owned by the living and refuse to be gatekept. Things now “mean” the concepts they generally elicit rather than what they may have elicited in the past. In this case, the purist concept is tracked by the newer terminology; the ‘misperception’ is now disambiguated into its casual non-practioner use. By claiming both terms still label one concept, you are not among the ‘plenty of us’ recognizing convention evolved, and we are aware you disagree. But props for still trying to hold the line!
Sorry, granted, there is a legal definition of ‘taking’. In this case, I didn’t intend to redefine ‘take’ as meaning not in possession. Instruction to “take a hammer and drive a nail” doesn’t mean one starts by robbing a store. Of course, the muddle over those rights is why the even further suggestion of ‘Libre’ over ‘Free’ over ‘Open’.
Put another way, I strictly agree with you, but it’s futile since in the end casuals define things. It’s not your Open Source, it’s Nacho Libre! ... (Sorry. :-)
> Just to clarify, I am okay with paid software existing.
"Open source" does not mean "you are not allowed to demand money". For example Fritzing ask the user to pay for the download (see https://fritzing.org/download/). It just means that you don't have a monopoly on distribution or asking for money.
> This allowed other apps like MonitorControl [1] and DisplayBuddy [2] to port some Lunar features (like DDC on M1) to their own code. So I'd say it's still useful enough.
When I was trying to do some iOS dev, I basically noticed that having open source or even open core projects accessible for free helped a lot. It ranged from some hard-to-google things, like "how should I structure this part of the code", to fulfilling the utter lack of good documentation.
So, thank you for releasing this!
I'm not sure if it still holds, but Blink app (for ssh, €21) could be built yourself, but I still paid for it because it seemed easiest. So there is some possibility to keep source open while offering a paid app. Not everyone is going to bother to build it.
>> Lunar can't be built from this repo yet as the source code for the paid features is hidden
This is where I feel a bit insulted. As long as you have stubs (as you say you will write) for the non-free parts, I can accept the reasoning. But an unbuildable repo is not a repo, in my view. I am not going to argue semantics here but this is the problematic part, for me. I think that after you publish the stubs it can be called an "open source Lite version" - but before that, it's just "unbuildable code taken from your real code"
This is from the MIT license, feel free to swap from most of the others:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> Then it would fit the strictest definitions of open-source (you are free to modify and redistribute), but would miss the community aspect completely due to misaligned incentives. I could add a great feature, but my pull request would be denied if it overlaps a paid feature.
Not every open-source project accepts contributions. This is something that you just interpret into "open source", but was never part of it.
What open source rather means is that you are free to create your own version/forks that you maintain by yourself if you want some personal code included.
> Not every open-source project accepts contributions. This is something that you just interpret into "open source", but was never part of it.
I do interpret it into it, as do many others. But not everyone. Stallman and the people at GNU have fought against the term "open source" for a long time, precisely because people have different ideas of it: https://www.gnu.org/philosophy/open-source-misses-the-point....
> What open source rather means is that you are free to create your own version/forks that you maintain by yourself if you want some personal code included.
That is commonly referred to as free (as in freedom, not price) software, which is the strictest interpretation of open source I can come up with. Note that others have other interpretations of 'open source' that are even more strict (you may only view the source code, for example, or you may modify but not redistribute the code)! I personally don't include 'binary virality' a-la GPL in this strictest interpretation, but again, some do.
Ultimately open source doesn't have one clear definition. In my book it means free software that is developed 'in the open' - accepting contributions from anyone based on merit. A more precise modern term would be FOSS - that is what I understand when I see open-source.
>> Not every open-source project accepts contributions. This is something that you just interpret into "open source", but was never part of it.
>I do interpret it into it, as do many others. But not everyone. Stallman and the people at GNU have fought against the term "open source" for a long time, precisely because people have different ideas of it: https://www.gnu.org/philosophy/open-source-misses-the-point....
Literally nobody interprets open source to mean you have to accept every (or any) random patch from anyone on the internet.
> Note that others have other interpretations of 'open source' that are even more strict (you may only view the source code, for example, or you may modify but not redistribute the code)!
wtf no... some people (microsoft) tried to do something like that branded as "shared source",but nobody considers that open source.
> Ultimately open source doesn't have one clear definition.
Really because the osi definition seems pretty clear to me.
Regardless, even if something is ambigious it doesn't mean you can make it mean anything you want. If i said, in my books open source is a breed of dog, people would say i am being stupid, because i am.
> That is commonly referred to as free (as in libre) software, which is the strictest interpretation of open source I can come up with.
No, it's really not part of what makes libre/free stricter than Open-Source. E.g. it's clearly something required through the Open Source definition: https://opensource.org/osd
> Stallman and the people at GNU
Free Software projects following the requirements of the FSF also do not have to accept contributions. It's completely orthogonal.
> No, it's really not part of what makes libre/free stricter than Open-Source.
I edited out the libre portion and I clarified in my comment that I don't (by default) include the 'binary virality' a-la GPL in my strictest interpretation, but some certainly do.
Strictest interpretation meaning here as in 'the bare minimum to qualify', not the one maximizing 'restrictions'. Again here not everyone agrees on even the term 'restriction' here, some would consider the binary source requirement of GPL a restriction, and others would consider it a restriction if they can't see the source of the binary program they're running.
> Free Software projects following the requirements of the FSF also do not have to accept contributions. It's completely orthogonal.
I never intended to claim that. My claim is that I (and many others) would consider accepting contributions based on merit as part of open-source.
Maybe my above comment was unnecessarily encroaching on the topic of whether something like the MIT license is "free" or "libre". Ultimately I think it's orthogonal to what my main point was, and I apologize if I misused any definition myself.
There's no version of OSS that comes with the contingent requiring its Authors to forever maintain or manage contributions for it. If they don't want to spend the time & effort to manage it, feel free to fork their OSS Software and maintain modifications yourself - that's what OSS Software enables you to do.
> Ultimately open source doesn't have one clear definition. In my book it means free software that is developed 'in the open' - accepting contributions from anyone based on merit. A more precise modern term would be FOSS
You're understanding of what Open Source Software is invalid, call what you want your OSS to be something else like "Collaborative Open Source" because your definition of what you think it is, is not in any OSI definition or certified license.
"Open Source" does have a clear definition [1], OSI certified licenses which meets its definition is available at [2]
I consider almost all my stuff to be "open source," even the couple of projects that are "source available."[0] I think that it's important to make it all available, if I will call it "open source," but there's no reason, in my mind, to make it so that people can just take my work and use it commercially.
That said, I generally like to use the MIT license, because I don't like coercive licenses. I just don't like it when people try to coerce me, so I won't do it to them.
I am currently working on a non-open-source/non-source-available project. Considerable parts of it are open-source (MIT license), but the core app code, as well as a modified variant of my BAOBAB server[1], are proprietary and locked away.
I don't think any of it is particularly awesome or worthy of secrets, but the folks I'm working with aren't as sanguine as am I, when it comes to opening the kimono, and I'll respect their wishes. I worked for years, for a corporation that had Fort Knox trade secret security. It's something that I'm used to doing.
> Note that others have other interpretations of 'open source' that are even more strict (you may only view the source code, for example, or you may modify but not redistribute the code)!
"Open source" means "open source as defined by the OSI" who actually invented this term. For the concept that you may view, but not, say, modify or distribute the source code, for some time Microsoft attempted to promote the term "shared source".
I also perceive a similar conflict of interest with the "open source but pay for support" model. A good deal of software I've come across with this model was perversely byzantine. If your users only pay you when they're confused, there's negative incentive to make it less confusing.
Citizen in what? A free labor pool for billion dollar companies and hustle culture bros who want to rebrand some FOSS and slap a control panel on it for a quick SaaS flip?
FOSS is supposed to be a gift culture. You give back by making your own, fixing bugs, doing volunteer tech support, or yes paying the creators or a company or foundation that pays them. You don't just take and then whine about "gimme my free stuff," but that's the attitude that many people seem to have adopted.
Another thing I really dislike is the ecosystem being dominated by surveillance capitalist companies. They have a vested interest in using FOSS to steer the ecosystem in ways that benefit them and their interests, and I don't like the direction they are likely to take things. Unfortunately they have plenty of money to "dump" high-quality open source on the market in order to exercise leverage over it. This isn't charity. It's a control technique.
I am personally starting to dislike the OSI for pretending these issues don't even exist. If you look at who funds OSI it's completely captured by mega-corporations, mostly in the surveillance capitalist space.
Open source needs a steward that cares about the freedom part more than the free part.
FOSS is “supposed” to be about individual liberty of the lone user to make any changes needed for themselves, and the right of that user to publish those changes as they see fit. Nothing more.
Otherwise, I agree with you. If you want to stave off corporations doing this, you should use the AGPLv3 license.
What would be some good options to get paid for open source?
In this case, is this an application that could be distributed via the app store?
The issue with making money off open source tools like this is that it's often aimed at tech savvy people / developers already, who can easily find the binaries to install themselves for free.
> What would be some good options to get paid for open source?
Many might read this as "good options to get paid money in exchange for open-source source code". Then the answer is simple: you can, but only once. The code is freely redistributable without restrictions by anyone, thus no scarcity that one could get paid for exists after the initial sale (if the sale ever existed).
So I think a better reading of the question is "good options to paid as an open-source developer".
One could have a money pot for certain features of the software (which may or may not be done yet), that interested users can contribute in or outright buy, which you would then develop (or publish). E.g. "I will develop UTF-16 support in FooApp for $5000". This is especially interesting for open-source software used by enterprise. The problem* here is someone else might offer to do it for less (including free). A bad incentive here is that if you also control the "canonical" repository or project, you can reject pull requests for features that you intend to sell.
An alternative is donation-ware, either through the project or directly to you as a person. The problem* here is that whoever controls the landing page of the most popular fork decides where the majority of the donations go to.
Why did I highlight problem with an asterisk in both cases? Because they have a common cause: we would like to think that if we're the original author of a piece of open-source software, we are in some way special. The original, authentic, canonical, "real" software. We deserve to get paid for it, and no one else should. And people tend to agree! But as per my opening paragraph - the exclusivity is inherently gone. So economically, we can't be. And I don't think a good 'solution' for this exists, although I admit I haven't thought about it enough.
You have to appreciate how much effort goes into creating this piece of software, everything from the app to the changelog looks like a work of art.
I think your definition of open source is a bit corrupted, and skewed towards expecting people to work for free in perpetuity. The Lunar repository contains open source code, and you should not expect it to compile without errors, nor should you expect maintainers to accept patches.
They don't owe you anything, and they already gave you more than most developers will do through their entire careers. I think it's perfectly understandable that the developer tries to find ways to make such a high quality project sustainable and profitable in the long term, and it won't help anyone to diss on them.
Good software is hard, I expect developers to make a living, and have zero expectations of them open sourcing it or distributing it for free. I am happy to pay for useful software and while I think open source is great, I don't veer into "information wants to be free!!1" idealism.
That being said, open source has both formal and colloquially accepted definitions. Not withstanding anything in my previous paragraph, I support holding accountable any entity, large company or individual developer alike, to conform to that notion once they choose to make a claim of being open source.
I. E. You don't Have to make it open source, but if you claim you do, then you actually should :)
"This product is so incredibly amazing that you should be grateful to us that we allow you to use it at all, and not ask any awkward questions about the restrictions we've placed on how you use it" is such a 'Apple' answer :)
To be honest, some of it should be native to macOS.
Some of it is very smart (like using your monitor as a soft box for online calls)!