Is an Open-Source Core Really That Big a Deal?

[speechles 1917]

27 people in total have participated. Are you saying 5 or fewer prefer open source?

 

Those who instill the virtues of Open Source freedom appear to be 5 or fewer of the participants in the thread. Yes. I meant I can count on one hand the number.

 

If it is more than I can count, both hands every finger, it becomes many. Until you need to take off your shoes to keep counting It is a few.

[Chyron 221]

You get more bees with honey than you ever will with vinegar.

Flies. Not bees. You catch more flies with honey than with vinegar.

[BAlGaInTl 279]

So what I've been trying to drag out is where in that spectrum that you describe, the Emby team stands.  This will help with knowing the future direction of the project.

Maybe I missed the mark, but in that analogy and made up numbers:

 

90% - People that don't care what their software license is, and only care about the features

9.9% - People that recognize the benefits of OSS and closed source, but are still primarily concerned with features

0.1% - People that think OSS can only be libre, it's the primary reason they select software and place it's value over features. Software that starts as this can never transition to another license regardless of intentions.

 

I would say that in these highly fictional numbers, the Emby team would proudly stand in the 9.9%. Their primary concern is the features and useability of the software that they can produce given resources (time and money). They found that in order to continue to progress, the license needed to change. They are okay with that, just as they are okay with the Jellyfin fork.

[speechles 1917]

Flies. Not bees. You catch more flies with honey than with vinegar.

 

 

 

https://www.barnesandnoble.com/p/you-catch-more-bees-with-honey-than-with-vinegar-wild-pages-press/1130021782/2660891987170

 

I need a new notebook... lol.

Edited January 31, 2019 by speechles

[Chyron 221]

they are okay with the Jellyfin fork.

I'm... not so sure about that.

 

I'm glad we could give them a 5 year head start on that glowing feeling.

[BAlGaInTl 279]

I'm... not so sure about that.

They are okay that the code forked.

 

They may not be okay with the way the new project is promoting itself.

 

At least that was my interpretation.

[ebr 14910]

I'm... not so sure about that.

 

 

You cut off the second part of my statement .

 

They are fully within their rights to do what they are doing.

[Jdiesel 1113]

In the interest of keeping the discussion going and civil, does anyone have an examples of a successful bounty based funding model where the users put money forward towards the completion of features they want do see? I would imagination that eventually the product would become so feature rich that users would have no reason to donate for more.

[metsuke 27]

In the interest of keeping the discussion going and civil, does anyone have an examples of a successful bounty based funding model where the users put money forward towards the completion of features they want do see? I would imagination that eventually the product would become so feature rich that users would have no reason to donate for more.

I haven't seen bounties as a main source of income, but regarding operating systems, I very often see sponsored features and bug fixes by companies.

[Tur0k 143]

Here, I am already a premiere member thus I don’t mind the change. I switched to Emby a few years ago from just using multiple iterations of Kodi and later adding a local DB for central management.

 

What I found in Emby was a vastly superior to that Kodi solution.

1. Central management of watched shows/movies.

2. Remote access.

3. Live TV.

4. DVR.

5. Better user management.

6. Better forum activity than other competitors in the same offering space.

7. While the total solution has a higher up front cost (software, services, and hardware). After the break even point it is a far lower monthly cost of ownership than a TiVo/cable provider DVR with multiple clients ent devices.

 

The only complaints I have seen are the lack of real RW-FF, and I once did have to delete my DB and recreate in order to get DB improvements, but those are very minor.

 

While I do like open source software and I do use it in multiple places (PFSense, Freenas, nextcloud for example), I can understand that it can be difficult to maintain 2 separate branches (paid and community edition). I would have hoped that Emby could have maintained two separate editions (paid, and open source) I do know that in some cases the two solutions become inherently too different from each other and then must have more than one group of devs to maintain it.

 

I have found that the Emby dev team does a great job IMO. For me things have consistently improved over time. I have no plan to move as long as I get to:

1. keep my system proxied to the public Internet privately.

2. My watching habits are not monitored and sold to the highest bidder.

3. Freedom to run commercial removal.

 

While I looked up the new fork and I hope they do great things. For me the positive improvements that have been made thus far are more than enough for me to keep using Emby.

 

 

Sent from my iPhone using Tapatalk

Edited February 1, 2019 by Tur0k

[adamstewiegreen 147]

After reading most this thread my thoughts are this:

 

1. Open/closed source doesn't really effect me

 

2. Open source without contributors might as well be closed source.

 

2b. Auditors who don't contribute (i.e. fix code) aren't auditors, they're just browsing code.

 

3. Did the jellyfish crew have their thumbs up their ass all this time? Seriously. Why contribute to jellyfin now but not to Emby earlier? (That doesn't make sense).

 

3b. I actually checked, from what I can see the jellyfin people had never contributed to Emby.

 

4. If you don't contribute to an open source project, you have no say if it goes closed source.

 

5. Monetizing open source projects seems to have unique challenges.

 

6. There seems to be a false equivalence between free and open source.

 

7. There seems to be a false sentiment that free is better.

 

8. "Too many cooks spoil the broth" and I think this is somewhat true of Kodi.

 

Personally, I think @@Luke and @@ebr have every right to decide to make it closed source and based on interactions in this forum and the release of Emby 4, I am more than happy for them to make decisions and move Emby forward.

[metsuke 27]

Thanks for your time and sharing your thoughts.  It does help the conversation, and help each other understand each other's perspective.  I have some questions for you that could assist my own understanding of your point of view.  I ask not to convince, but to gain detail to general sentiments (not that your statements are too generalized, but it seems like most posters just make vague notions, then leave).

 

1. Open/closed source doesn't really effect me

So would this also imply that you do not care for you or any 3rd party to review the code you deploy on your server?  This would require that you trust the Emby team and anyone they contract, for as long as you use the software.  Do you trust all developers for all your software?

 

For my part, I do trust the Emby team, as the code that I and others have reviewed has been of good measure, and the team has a good reputation.  However, my nature, bad experiences, the nature of the internet, people...etc prevent me from fully trusting without a mode by which to verify.

 

 

2. Open source without contributors might as well be closed source.

2b. Auditors who don't contribute (i.e. fix code) aren't auditors, they're just browsing code.

Do you see contributions as the only benefit to an open source software?  If so, do you disagree with any of the other arguments made for benefits of open source software?

 

I'm a little confused about the auditors statement, since companies who do audit, for large portions of money, do not fix code, but just tell you that there is an issue.

 

I'm guessing that you don't think the "many eyes" benefit actually exists for bug fixes or security concerns.  However, if you were to presuppose that having "many eyes" on a project actually did fix more bugs, and find security concerns, would you still see it as irrelevant?

 

 

4. If you don't contribute to an open source project, you have no say if it goes closed source.

The only people who really have a say in such a thing are the license holders of the software utilized in the project, and the owners of the project.  Even contributors might not have a say, even if it seems uncouth to shut them out.

 

 

6. There seems to be a false equivalence between free and open source.

 

7. There seems to be a false sentiment that free is better.

Agreed, supporters of open source come in many forms.  Demands that software be free may not be realistic, which is why many models compromise and have a CE and EE version.

 

I would say that free (or partially free) is only better if the team/company does not lose revenue (and may even gain revenue and popularity).  With the presupposition that this is a valid, even common, scenario, would you agree that a free (support model) or partially free (CE/EE model) can be better?

 

 

Personally, I think @@Luke and @@ebr have every right to decide to make it closed source and based on interactions in this forum and the release of Emby 4, I am more than happy for them to make decisions and move Emby forward.

They and those they employ have the only right to decide the fate of the Emby project since it is theirs.

[legallink 187]

So would this also imply that you do not care for you or any 3rd party to review the code you deploy on your server?  This would require that you trust the Emby team and anyone they contract, for as long as you use the software.  Do you trust all developers for all your software?

 

For my part, I do trust the Emby team, as the code that I and others have reviewed has been of good measure, and the team has a good reputation.  However, my nature, bad experiences, the nature of the internet, people...etc prevent me from fully trusting without a mode by which to verify.

@@metsuke with respect to this statement, is there some action here that would lessen this concern in some way?  I guess what I'm asking, is there are a viable alternative to the "trust" factor as it relates to the "many eyes" theory or is it only possible in the open source environment?  If Emby were to get an audit of the code, what would the audit be for?  Privacy/data transmission/resource utilization/code efficiency/.  I'm just trying to wrap my head around what the nuts and bolts of the concern/request are and how Emby could solve that (given that they have gone closed source).  Also do you have vendors you recommend?

[metsuke 27]

@@metsuke with respect to this statement, is there some action here that would lessen this concern in some way?  I guess what I'm asking, is there are a viable alternative to the "trust" factor as it relates to the "many eyes" theory or is it only possible in the open source environment?  If Emby were to get an audit of the code, what would the audit be for?  Privacy/data transmission/resource utilization/code efficiency/.  I'm just trying to wrap my head around what the nuts and bolts of the concern/request are and how Emby could solve that (given that they have gone closed source).  Also do you have vendors you recommend?

Those are good questions.  As with many aspects of the open source community, everyone wants something different, which some might say can only be satisfied by having an open source, but my own preferences are more mild.

 

Mostly I'm personally concerned with both intentional malicious activity and violations of privacy that may be seen as innocent. I've only ever paid Veracode for auditing.  I don't think they look for privacy concerns but they might if you ask. A code audit by just about anyone would soothe the voice in the back of my head reminding me of the times I was fooled.

 

Certainly, I'd still be missing the ability to modify the behavior of Emby locally via a code change, but I hadn't gotten that far yet in my usage, and it is not a difficult thing to give up.

[legallink 187]

@ it sounds like your concerns are more security related than privacy related?  Or is it really both?

 

My questions around audits to address the notion that typically when people are doing code audits, its not related to data collection, which is why I think if we can put together a specific proposal that alleviates significant concern, that would most likely be more easily be digested than just saying "I can't audit the code".

 

That being said, I don't know that it removes the concern, it just might be a step in that direction.

[metsuke 27]

You can still do a lot of pen testing and data leakage detection by treating the program/service as a black box. A lot of external companies do that when testing and certifying apps.

 

https://www.veracode.com/security/black-box-testing

 

In fact there are a bunch of free os pen testing tools out there we should be using to test this app. Perhaps we need to discuss that avenue as well. However I did not see anyone doing audits and code checking when the app was completely OS so I don't think there will be a big rush to do this.

 

But black box testing is easier for none coders to do and perhaps that is something the user base can do to help people feel at ease?

You're right that there weren't any official audits done by community members and also that there ought to be black boxes testing as well.  I should mention that I typically sift through every commit, even if I'm not as familiar with the language, since more obvious issues can be revealed quickly, but that can certainly be traded for a 3rd party doing a more methodical review.

[speechles 1917]

I can kick this off.

I have noticed that images are not secured at all

 

http://<your ip>:8096/emby/Items/<id of item>/Images/Primary

 

the ID is now an integer so you can just guess a bunch of ints, it is easy to sweep scan a public server to get a list of images of their items thus knowing what is in the lib. Some might say no big deal, other would freak out.

Perhaps I need to spend some time doing some proper pen testing and see what happens.

 

http://<your ip>/emby/Items/Prefixes?IncludeItemTypes=Series,Episode

 

Series,Episode can be any Item Types. Not sure how useful knowing prefixes is but it isn't secured either.

Edited February 1, 2019 by speechles

[Fayth 8]

Just chiming in with my 2 cents.

 

I purchased lifetime emby premiere in 2015 or somewhere around there, but open source is important to me.

 

I understand the Emby developer's viewpoint on this and have no issues with them changing their model, but the change could certainly drive me to other options, as I continue to move more and more to using open source tools in general.

 

Emby being open source is actually what drove me from Plex originally, where I also have a lifetime premium account.

 

Not everyone supports open source because they want to avoid paying for things. Hell, I'd guess most of you Emby premiere subscribers pirate all your media, and here I am buying and ripping blu-rays to build my collection.

[eviltizzy 0]

I too have plex and emby lifetime memberships and do not like that emby went closed source..

[speechles 1917]

I too have plex and emby lifetime memberships and do not like that emby went closed source..

It is as it always was. The last metroid is in captivity the galaxy is at peace.

 

In this climate open source applications are being "raped" by forking. Removing paywalls, adding functionality that goes against licenses/TOS, etc.. There is a reason Emby curated its own plugin store and had no way to "tie" unofficial plugin stores into Emby. There is a reason things can't just be scraped off the web with regular expressions. This is because doing that is akin to stealing. Emby has gone a different direction and instead of continue to suffer at the hands of these... "rapists"(can we call them that.. lol).. It is protecting itself. This isn't because of anything else other than it is costing real money for added functionality.

 

Also at the end of the day. Emby is a company. Companies need to protect their investments. They need to be careful of how they share information with the competition. They must understand the risk and reward of going closed source and I believe they do. Users need to understand these risks and rewards and have them explained. That is what is lacking in this thread.

 

I can start in that area..

 

Risk:

1. Emby might have a bug that close inspection of the code could discover. White hats would report. Black hats would exploit.

(50% help/50% damage - no risk and no reward)

2. Emby could close up tomorrow and disappear with its proprietary code and you can never build it again.

3. Emby could be sneakily installing nasties:

(install trojans, install malware, install VOIP robo-autodialers, steal your passwords, install rootkits, install keyloggers, tunnel your network to allow intrusion, etc)

 

Reward:

1. Emby must correct its mistakes in the code and this prevents others from spotting those holes and exploiting them or reporting those holes and how to fix them.

(50% help/50% damage - no risk and no reward)

2. Emby features can now include proprietary tie-ins to 3rd party products. Such as the liveTV guide provider. These could not be done under open source.

3. Emby has to hire developers - More developers required now that the code is closed and internal - faster server/app development - paid developers means motivated development.

 

Anyone care to add to the list above?

Edited March 31, 2019 by speechles

[Gilgamesh_48 943]

I too have plex and emby lifetime memberships and do not like that emby went closed source..

 

I also have both and I could care less if either is open source, closed source, mixed source or non-sourced. As long as the system works for me it is perfectly fine with me. I know that sounds a bit selfish but it is how I feel. Nothing matters as far as software is concerned unless it impacts my ability to consume my media and how the code is handled does not have any impact on my consumption.

[metsuke 27]

I also have both and I could care less if either is open source, closed source, mixed source or non-sourced. As long as the system works for me it is perfectly fine with me. I know that sounds a bit selfish but it is how I feel. Nothing matters as far as software is concerned unless it impacts my ability to consume my media and how the code is handled does not have any impact on my consumption.

I can't fault you for not having the same values as others.  We all have different aspects of technology that we care about.  I'm sure in the automobile industry, there are many different schools of thought about a great many related subjects, and I am ignorant of pretty much all of it.  So with regards to automobiles, I just want them to work, much to the chagrin of my mechanic father-in-law.

[Lawrage 13]

Another Plex and Emby lifetime subscriber here, I have no issues with Emby going the way it is.

 

I need software that works, whether it be open source or not, free or paid. As long as Emby keeps working and keeps up with what the customer base needs I will continue to use the software.

[mholloway 0]

Looong time Emby user and frequent advocate here. When I say frequent, it's literally a house party trick, a bus-ride trick, and the home team I root for in the face of any Plex fans.

 

I chose Emby back in 2014 cause it was robust, full featured, and offered great, nice-to-have (but not critical) features like trailers and movie posters in the premiere subscription. As bunny huang would say, "Better fences make better neighbors", and my experience with Emby so far has been ideal in this regard when it comes to FOSS vs Proprietary features.

 

I think I've had my premiere subscription for almost 3 years now, and the Emby dev team has to be the most consistent small team on any FOSS project I've seen so far.

 

All that withstanding, a move in a more closed-source direction would absolutely have me looking at other options; Plex's works-or-it-doesn't, black box functionality had me reeling minutes into using it.

 

I really hope Emby continues to be largely GPL licensed and the flashy features I enjoy in Premiere stay light on resources and telemetry. I can afford $5 bucks a month nearly indefinitely; I can't afford to use Plex (or anything similarly proprietary) at all.

 

Cheers