Jump to content

Roadmap transparency: i.e. How many upvotes does a Feature Request need before you actually implement it/work on it?


BlazedMonkey

Recommended Posts

BlazedMonkey

Feature request:  Roadmap/Development transparency

 

 

In scrolling through the current feature requests, and having put in a few myself, I'm curious:  How many upvotes does a feature request need to get before you guys actually start working on it?  Is there a certain number of votes per period of time, or how do you decide what actually gets worked on?  I ask because I often see a feature request, and the response is generally something along the lines of:

 

If the Emby Team already agrees with the user, the script goes:

Emby team - "It's something we'd like to do in the future, thanks."

But no timeline is given.  A year goes by and it still hasn't been implemented, so the user asks again, and gets a response similar to:

Emby team - "We are working as hard as possible to make everyone as happy as we possibly can. Thanks."

User gets frustrated, asks for an ETA, response is like:

Emby team - "Hi.  We have never stated this feature was slated for any particular release.  It is planned for the future but not under active development yet."

2.5 years have gone by for this feature request, with almost 30 upvotes, and active development isn't even on the horizon.

 

 

If the Emby Team disagrees with the user request, the script goes something like:

Emby team - "This is why we think the way we are doing things is right, thanks"

Users - "Hey, I see what you are saying, but here are 9 reasons I disagree"

Emby team - responds to 1 point of the 9 made to tell the user they are wrong, or that that 1 little point isn't relevant, ignores the other 8 points

User - gets frustrated, keeps pushing

Emby team - "This thread is here to gauge user interest, we will see how many upvotes it gets and may implement it in the future"

Years go by, thread gets upvoted, feature never gets implemented.

 

 

The highest upvoted feature request right now in the top 20 pages of this forum has 63 requests (not even counting how many similar threads may have been locked for being duplicates), and it's not even under active development at this time, despite being created by a developer and being over 2.5 years old.

 

 

 

 

To get ahead of some of the responses I'm sure I'll get, let me just say:

-I absolutely appreciate that Emby exists, and I appreciate and respect the time that goes into its creation and development.  I know that developing a program takes time.

-Yes, I am a premiere subscriber

-No, I'm not just trying to complain about this.  I am simply asking for realistic responses that actually have usable substance and transparency.  Some actual follow through or a roadmap so that users know if their requests are even being considered for active development, rather than waiting for ages only to be told that the item they thought was getting worked on or had a chance at being worked on isn't anywhere on the horizon.

-Yes, I do really love Emby, and I want to see it grow and get better, which is why I have chosen to give you guys my money, and why I recommend it to people.  Unfortunately, that doesn't negate my frustration with this current process.

  • Like 22
  • Agree 1
Link to comment
Share on other sites

Hi.  What you have to realize is that being "transparent" to you is being transparent to everyone - including our competition.   So, that is one reason you are not going to see a lot of definite commitments on exactly what is under development at any given time or when things will be released.  We usually will tell you when something is actively under development but may not be able to provide much information before then.

 

There is no hard and fast number for a request and, while we want the feedback out here to gauge user interest in these features (and just give us ideas we haven't thought of), most times, there are a lot of other factors that have to be considered.  One of the most common is complexity of implementation and how much of an impact it will have on the system overall.  Very complex items that impact everything take much longer for us to be able to commit to - and, sometimes, even if the entire community wanted them, they may not make sense to implement just due to their cost or other impact on the system.

 

Also, this wasn't within the scope of your questions, but many times we see people pop into a three year old feature request with a comment like "its been 3 years why hasn't this been done yet".  Well, when that comment is the first activity that item has had in 3 years, then that actually tells us that not many people are interested in it.  That is just to say that the amount of time a request has existed is not a very good gauge for whether or not it should be implemented :).

 

We value everyone's ideas and requests and do really try to react to them as best we can - along with keeping up with all the changes in technology we need to and the competition.

  • Like 6
Link to comment
Share on other sites

Sammy

The Emby team is extremely small and very active on these forums assisting with issues and responding to requests.

 

The product grown way beyond what I ever expected it to be 6 years ago. I think that they are doing a fantastic job and have Incorporated a lot of feature requests.

 

Kudos!

 

Sent from my SM-G960U1 using Tapatalk

  • Like 5
Link to comment
Share on other sites

pir8radio

Hi.  What you have to realize is that being "transparent" to you is being transparent to everyone - including our competition.   So, that is one reason you are not going to see a lot of definite commitments on exactly what is under development at any given time or when things will be released.  We usually will tell you when something is actively under development but may not be able to provide much information before then.

 

There is no hard and fast number for a request and, while we want the feedback out here to gauge user interest in these features (and just give us ideas we haven't thought of), most times, there are a lot of other factors that have to be considered.  One of the most common is complexity of implementation and how much of an impact it will have on the system overall.  Very complex items that impact everything take much longer for us to be able to commit to - and, sometimes, even if the entire community wanted them, they may not make sense to implement just due to their cost or other impact on the system.

 

Also, this wasn't within the scope of your questions, but many times we see people pop into a three year old feature request with a comment like "its been 3 years why hasn't this been done yet".  Well, when that comment is the first activity that item has had in 3 years, then that actually tells us that not many people are interested in it.  That is just to say that the amount of time a request has existed is not a very good gauge for whether or not it should be implemented :).

 

We value everyone's ideas and requests and do really try to react to them as best we can - along with keeping up with all the changes in technology we need to and the competition.

 

 

I've often wondered, why do you care if your competition knows what you are adding to emby?  Who cares if they steal the idea and push it out faster than you, they could just pluck the good ideas from the feature request section here anyway right?   You are not really losing customers?  I mean I don't think emby users are going to rush away from emby to try another server due to a little new feature. 

  • Like 14
Link to comment
Share on other sites

rbjtech

I've often wondered, why do you care if your competition knows what you are adding to emby?  Who cares if they steal the idea and push it out faster than you, they could just pluck the good ideas from the feature request section here anyway right?   You are not really losing customers?  I mean I don't think emby users are going to rush away from emby to try another server due to a little new feature. 

 

This - and more importantly to a lot of people, the one thing your competitors cannot 'steal' is the impeccable support and the fact you are open to new ideas and community lead decisions. 

 

That is what sets you apart from the others, they all play video, they all have bells and whistles - but if something doesn't work in Emby, you and the community will do our utmost to fix it - with the competitors, you are likely on your own.

  • Like 4
Link to comment
Share on other sites

I've often wondered, why do you care if your competition knows what you are adding to emby?  Who cares if they steal the idea and push it out faster than you, they could just pluck the good ideas from the feature request section here anyway right?   You are not really losing customers?  I mean I don't think emby users are going to rush away from emby to try another server due to a little new feature. 

 

That is only one factor but, no, we're not crazy about being beaten to the market with features.

 

The reality is that, even if we wanted to be "completely transparent", I believe it would just cause more trouble than anything else.  We are extremely agile in our plans and are constantly reacting to feedback and other influences to improve the system.  This often means that things we plan even a month or so out, change.  If we tried to publish this then, many, many times we would just miss expectations and make people even more upset.  You usually know about new things once they hit the beta stage.

 

We can do a better job of selecting and prioritizing some of these feature requests, however, and we will strive to do that.

  • Like 5
Link to comment
Share on other sites

Richard Branches

From my personal experience at least they respond with phrases like that, PLEX team and their messy forums are the worst, they never answer to you to say nothing about anything, that's the main reason I switched to Emby in the first place, here they listen to me no matter if what I asked is ever implemented.

 

By the way, I've seen some of my feature requests come true.

Edited by Richard Branches
  • Like 3
Link to comment
Share on other sites

BlazedMonkey

Hi.  What you have to realize is that being "transparent" to you is being transparent to everyone - including our competition.   So, that is one reason you are not going to see a lot of definite commitments on exactly what is under development at any given time or when things will be released.  We usually will tell you when something is actively under development but may not be able to provide much information before then.

 

 

I get where you are coming from, but the thing is, it's going to happen one way or another.  You aren't making a unique product here, so you can't expect that other competitors won't have the same functions and features as you, as there is nothing truly novel about what we are doing here.  Apple constantly gets beaten to the punch on features by other phone manufacturers, yet you don't see them going out of business, or exiting the phone market because someone implemented fingerprint ID before they did.  Among all the things Apple is known for, they do 2 things extremely well:  First, they have excellent customer service and support. Second, they are smart enough to realize that there is a natural flow to the way people expect things to work, and they are very good at shaping their products to follow that flow.  So when people point out something that doesn't make sense (like this), which is simple to fix (this is literally changing the order of a few lines of code, or alternatively, adding a flag to show that there are extras), it's frustrating to get rebuffed (see my first post above re: If the Emby Team disagrees with the user request)

 

As pir8radio pointed out earlier in this thread, if people really wanted to steal your features, they could look at your product, then look at the forums for what people are requesting, and implement the features themselves.  What keeps them from doing this?  Well, for major things, it's like you said earlier:

 

 

Very complex items that impact everything take much longer for us to be able to commit to - and, sometimes, even if the entire community wanted them, they may not make sense to implement just due to their cost or other impact on the system.

 

 

If you know that, your competition knows that as well, and either: 1. They won't do it either, hence not beating you to the market, or 2. They will spend WAY too much time working on that one thing, thus falling behind YOU, and surprise surprise, you still win. 

 

The only thing keeping your users in the dark does is frustrate them, and cost you more time closing and merging redundant threads on here asking for the same thing.  If we had some kind of roadmap to reference, we would at least know something is on the horizon, instead of going almost 2 years in a thread thinking it was on the horizon, before finding out it's not even under active developtment:  For reference

 

 

 

There is no hard and fast number for a request and, while we want the feedback out here to gauge user interest in these features (and just give us ideas we haven't thought of), most times, there are a lot of other factors that have to be considered.  One of the most common is complexity of implementation and how much of an impact it will have on the system overall.  Very complex items that impact everything take much longer for us to be able to commit to - and, sometimes, even if the entire community wanted them, they may not make sense to implement just due to their cost or other impact on the system.

 

 

Let's be honest here, liking a post really does nothing when it comes to feature requests.  Look through the first 5 pages of the feature request section and you'll see that the vast majority of posts that have over 10 "likes" are at or well over a year old, and have yet to be implemented.  The highest upvoted feature request right now in the top 20 pages of this forum has 63 requests (not even counting how many similar threads may have been locked for being duplicates), and it's not even under active development at this time, despite being created by a developer (i.e. you) and being over 2.5 years old.  If THAT feature request can't even get implemented, why would anyone bother to upvote anything, after seeing that go nowhere for 2.5 years?  Despite this, your go-to response for users is still, "Liking the original post on these topics is the best thing to do."  

 

As far as simple requests vs. complex ones, well, I already addressed the complex.  For the simple ones, it goes down exactly how I described in my first post that started this thread.  If the Emby team agrees with you, you might have a chance at getting it implemented (granted, it will be at some unknown date in the future, and maybe not even then).  If they disagree, you get the script.

 

 

 

Also, this wasn't within the scope of your questions, but many times we see people pop into a three year old feature request with a comment like "its been 3 years why hasn't this been done yet".  Well, when that comment is the first activity that item has had in 3 years, then that actually tells us that not many people are interested in it.  That is just to say that the amount of time a request has existed is not a very good gauge for whether or not it should be implemented  :).

 

We value everyone's ideas and requests and do really try to react to them as best we can - along with keeping up with all the changes in technology we need to and the competition.

 

 

 

 

This is part of the "Transparency" I was talking about.  As I explained earlier, this is more often than not because you guys give convoluted answers that leave people thinking things are getting worked on, when in fact they actually aren't.  If I think something is being worked on, I'm not going to bug the developers about it and bump an old thread.  Look at any one of those threads you are thinking about, and you will see the same pattern of a convoluted answer, no activity for a while while the users think it is getting worked on, then after a year somebody pops in and asks why it hasn't been implemented, cue another convoluted response, wash rinse repeat.

 

In addition to that, keep in mind that you have FAAAAR more server admins on these forums than you do just regular emby users.  So while you may be speaking with only one admin, that one person could be representing 20 different users that are on their server asking for the same thing.  I'm sure you guys have hard numbers on emby users vs. installed server instances, so it can't be hard to understand that you are dealing directly with only a tiny fraction of the people who actually interface with your service.  It's like voting in the general election:  How many people are registered vs. how many actually turn up at the polls.  Just because you don't have 1,000 people beating down your door to get a feature request implemented (i.e. "liking" the post, or adding their commentary), doesn't mean that there aren't still 1,000 people out there that want the feature.  Just like you have a huge number of users with only a small number of admins, you have the same thing within the admins themselves:  Out of all the admins, there are only a fraction of those that are going to get on these forums and put in feature requests to begin with.

 

 

 

 

That is only one factor but, no, we're not crazy about being beaten to the market with features.

 

The reality is that, even if we wanted to be "completely transparent", I believe it would just cause more trouble than anything else.  We are extremely agile in our plans and are constantly reacting to feedback and other influences to improve the system.  This often means that things we plan even a month or so out, change.  If we tried to publish this then, many, many times we would just miss expectations and make people even more upset.  You usually know about new things once they hit the beta stage.

 

We can do a better job of selecting and prioritizing some of these feature requests, however, and we will strive to do that.

 

I'm not going to go back and reiterate, I think I've already responded to all the points in your first 2 paragraphs. I bolded that last line because it epitomizes everything I've been trying to explain throughout this post.  I will end with this:

We appreciate what you guys are doing, and we thank you for doing it.  I wouldn't be a premiere subscriber if I didn't like the vast majority of Emby, and want to help it improve and grow.  That being said, things would go much smoother for both your users and yourselves if we had more information, and some realistic responses that didn't come off as completely canned while providing zero definitive information.  I for one appreciate the dialogue we are having here, and you taking the time to respond.  Thank you for listening and continuing to have a constructive discussion with me, so that maybe things can get better for everyone  :) 

  • Like 10
Link to comment
Share on other sites

As I said, we need to do a better job of using this feature request forum for future work.  Point taken.

 

It is interesting that you used Apple as an example because they are the most tight-lipped company out there.  You NEVER know what they are working on until it is a week from release.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...
b0dyr0ck2006

I must say that blazed monkeys clear and defined posts on this thread are one of the best I have ever read here and echo his thoughts whole heartily. He is bang on the money with everything he has said, and in fairness to EBR he always takes the time to respond clearly and with intent - unlike one other Admin who I wont mention.

 

This is a very serious issue that needs to be rectified as a priority, as pointed out, you are mainly dealing with Server admins and not general users. Who gives two figs about the competition, competition is great for everyone

  • Like 4
Link to comment
Share on other sites

schmitty

Yes. EBR is very good with the customer relations side of things.

  • Like 1
Link to comment
Share on other sites

informaweb
I wish there was more info on the changes made. I'm looking at the changelog on Github to find out what's new (which allows me to know if I'm going to install the latest beta or if I'm waiting for the next one, but there are things that do not tell me anything at all.

I would like you to make a closed thread containing the details of the modifications made.

 

Example: "fix exit button web app"

- The button to exit the web application was no longer responding.

 

Obviously, this is a simplistic example, but on things like:

- Fix sample files not being ignored in certain situations

- Fix xmltv quality tag parsing (we do not know anything and the wiki is not really up to date either)

- Hauppauge fixed tuner

And so on...

 

Since it's already created or corrected, it does not bother to explain a little more what was created or modified, right?

  • Like 3
Link to comment
Share on other sites

I've often wondered, why do you care if your competition knows what you are adding to emby?  Who cares if they steal the idea and push it out faster than you, they could just pluck the good ideas from the feature request section here anyway right?   You are not really losing customers?  I mean I don't think emby users are going to rush away from emby to try another server due to a little new feature. 

This is one of the things I miss about the source being 100% open as you could previously just view works in progress.  As far as Plex ripping off stuff from Emby, they have enough problems with their own code, redoing their own UIs in clients after botching them for 3 years.  They've spent a large portion of the last two years coming out with features/services to then remove them (cloud features) and they spend a lot of their time these days working on features they want users to have (podcasts, news, music services, etc) that they can monetize while removing competing features like channels and plugins.  Plex has just after 3 years, gotten their DVR to work 90%+ of the time correctly but only with a single EPG source and single "tuner type". They've got recently allowed someone other than the admin to set recordings!

 

As a long time user/supporter of both systems I can tell you that most of the feature requests here are also over on the Plex forums.  People on both platforms tend to want the same things (big surprise).

 

Plex is growing in a different direction then Emby these days and going after different feature sets as a whole.  Ironically, the bigger threat to Emby IMHO is JellyFin which is really Emby 3ish without the current Emby clients.  They are more "PR" then deliverable and doubt this will change much in the near term.  JellyFin is realistically 2 to 3 years behind current Emby at best case as they don't support the multiple platforms, multiple clients, NET framework, Guide data built in, the new features in clients like Video (BIF) snapshot support, etc...

 

JellyFin will likely expose more people to "Emby Lite" and then Emby then detract from Emby long term assuming JellyFin sticks around long enough.

 

To me this would be like MS worrying about a competitor with source code to Windows 7 32 bit being a competitor to their current lineup.  Just not going to happen (open or closed source).  More likely than not, people will would play with it to find they like it then when they discover the "real version" has a lot more features, clients and support then they pony up the $ to get the real version.

 

The person likely to run JellyFin is also the same person who would run Plex without subscribing as well, so really not a person to worry about as they likely would never be a paid user.

 

Agree, disagree?

  • Like 4
Link to comment
Share on other sites

I know on the Roku we take feature requests seriously. I myself make it a point to put these on our issue tracker as [Requests] and link back to the relevant threads. In this way it shows me on the issue tracker a number of both bugs and features we lack. This is honestly the best way for us to do this. But we cannot share this with our competition. It would be like handing them the notes we keep on the app. Handing them our thought patterns and how we think. Why would anyone need to see how our code works if theirs is different? Why would they need to see how we communicate internally? This is why we cannot open the issue tracker to everyones eyes.

 

I do make it a point as well to always use the word "Reference" in a post where I have put issues or features onto the issue tracker. In this way you have your transparency on the Roku side. I can give you that much. But I can't let you see what we discuss and how we discuss priority of what gets done on the Roku. I know time is a huge concern. Cost is a huge concern. How much time an item takes to implement increases its cost. The cost is okay IF it helps to grow an audience. The bigger the audience the more users who appreciate things. If the cost/time invested is monumental for little audience gain you see the problem.

 

As long as we keep taking positive steps forward and putting Your media Your way as the core focus things will get better. The stale features just need more light shined on them. Maybe they need added to each "things" issue tracker like I have done for the Roku. This helps keep the lights on. Then nothing gets kept in the dark.

 

This is a constantly moving target. Tomorrow brings new things. You need to stay focused on the future and not the past. What happened yesterday no longer matters. What have you done for me today?  ;)

 

 

Also: Jellyfin is not our competition. They exist for the lowest common denominator. This audience is okay to lose. This audience tends to pirate and expect everything is free on the internet. This is not the customer base we find attractive. We want power users who want the best local media server on the planet. We want you. :)

Edited by speechles
Link to comment
Share on other sites

I know on the Roku we take feature requests seriously. I myself make it a point to put these on our issue tracker as [Requests] and link back to the relevant threads. In this way it shows me on the issue tracker a number of both bugs and features we lack. This is honestly the best way for us to do this. But we cannot share this with our competition. It would be like handing them the notes we keep on the app. Handing them our thought patterns and how we think. Why would anyone need to see how our code works if theirs is different? Why would they need to see how we communicate internally? This is why we cannot open the issue tracker to everyones eyes.

This is revisionist history and a bit hypocritical. :)

 

Emby up until very recently Emby was exposed both for the source code and the issue trackers as a whole.  Then code started being closed source and both the code and issue trackers have essentially went private.  Emby was the "no body" for a long time as it grew.  It copied numerous features from Plex and other software like Kodi/XBMC.  It's a mute point if features were directly copied or if the features were copied due to user request or just because they made sense.  Point being, if a feature makes sense to have it will get added regardless if someone else has it or not, regardless of when it was added to another software or in development.

 

The open source/issue tracking worked extremely well previously when no one was worried about competition and just worried about MB/Emby and being the best it could be without worry or regard for other software.  Emby became very popular because of this.  The whole point of open source code was to allow the code to be used by others to improve software AND to appeal to people who didn't want to "feel locked in" to closed source code or development. Many people switched from Plex to Emby because of this originally, even when it wasn't as feature rich.

 

This isn't rocket science type code.  An idea can usually pretty easily be duplicated by any other software if they want it.  Users ask for the same features on different software so there is nothing honestly being protected by this.  Who ads a feature first is more about priority than who can rip off a competitor first.  The code base with the best devs will rule the day when all is said and done.

 

When you stop and think about it.  Emby would likely NEVER have been what it is today if it wasn't open in the beginning.  Why fight what helped you to become successful in the first place?

 

I do make it a point as well to always use the word "Reference" in a post where I have put issues or features onto the issue tracker. In this way you have your transparency on the Roku side. I can give you that much. But I can't let you see what we discuss and how we discuss priority of what gets done on the Roku. I know time is a huge concern. Cost is a huge concern. How much time an item takes to implement increases its cost. The cost is okay IF it helps to grow an audience. The bigger the audience the more users who appreciate things. If the cost/time invested is monumental for little audience gain you see the problem.

 

As long as we keep taking positive steps forward and putting Your media Your way as the core focus things will get better. The stale features just need more light shined on them. Maybe they need added to each "things" issue tracker like I have done for the Roku. This helps keep the lights on. Then nothing gets kept in the dark.

 

This is a constantly moving target. Tomorrow brings new things. You need to stay focused on the future and not the past. What happened yesterday no longer matters. What have you done for me today?  ;)

 

 

Also: Jellyfin is not our competition. They exist for the lowest common denominator. This audience is okay to lose. This audience tends to pirate and expect everything is free on the internet. This is not the customer base we find attractive. We want power users who want the best local media server on the planet. We want you. :)

I actually feel the same way about JellyFin as you. LCD is a good way to express that type of user.

 

IMHO Emby only has two software competitions.  One is Kodi which is open source but a different market.  It's great software but highly "directional" in  doing one thing well.  It basically is great for a standalone system but not to share media or to act as any type of client/server or to share media with family and friends.

 

Plex is really the only other software of similar nature to Emby.  Emby could literally give them the code every day along with any notes, tests, design and technical documents and it wouldn't matter.  The software is written in different languages with different structures, APIs and frame works.  The "idea" is really all that would matter as the code would be mostly useless.  That's assuming they were even interested in the ideas or could program well enough to incorporate these ideas at the pace Emby has been adding them.  99% of what gets added to Emby has already been talked about in the forum or is just common sense so all a "competitor" would need to do is read the forums here or their own to see the same requests and ideas.

 

Emby adds features to it's code at a rate AT LEAST 2 or 3 to 1 vs Plex.  With Plex said features get implemented at best 85% to 90% but never 100%. They never finish features properly which is why they bleed so many users to Emby.  Besides the technical reasons the other reason people used to switch was for the openness (being talked about here) and support of Emby.

 

Plex is far more interested in being the next Netflix/Amazon/Apple Music then it is being an Emby.  They have already started the slow death spiral in many, many ways.

Edited by cayars
  • Like 4
Link to comment
Share on other sites

The same people commiting code when it was open source still are in closed source. Take for example the Roku. The Emby Team is compromised of those same individuals for the most part. Nothing has changed. People get the same exact they did open source as they did closed source for most everything. The only thing missing is now the issue tracker isn't filled with nonsense and now it focused strictly on development, our roadmap, and our plans for the future and how to get there together. 

 

It isn't about taking the source away. It is about protecting it. It was being abused. People were not using it the way they should have. Forks were made to damage the Emby brand and take away monetization. There were efforts made to disparage Emby as this greedy big mean monster who just wants to take code others wrote and make a trillion dollars on the efforts of open source. Please.. There were issues in migrate to the new closed source model. And most things are still open that can be.

 

The Roku SG app was never open source. Never pretended to be. The Android TV app I believe is the same way. Same with Apple TV if I believe right. These apps never had public code and if they did the same people commit code to them as open source still are as closed source.

 

I don't get the argument that now people can't fix issues and solve feature requests now that they cannot see the code. They weren't doing that to begin with. Only a few were. Those few are now within Emby Team. The future is together.

 

As far as competition. Emby has really none. Plex is some BORG spaceship out to assimilate all media. It isn't just your media your way with plex. It is their agenda your media their way. They aren't really Emby competition. They serve a different customer. Emby is for the power user who wants more. More control. The customer who wants their media they way. Kodi is the closest competition to Emby. It also has a plugin to allow Emby to exist with it. Together. Together is the future. Kodi is more a partner than a competitor. It takes all kinds of fruit to make a fruit salad.

Edited by speechles
  • Like 2
Link to comment
Share on other sites

The same people commiting code when it was open source still are in closed source. Take for example the Roku. The Emby Team is compromised of those same individuals for the most part. Nothing has changed. People get the same exact they did open source as they did closed source for most everything. The only thing missing is now the issue tracker isn't filled with nonsense and now it focused strictly on development, our roadmap, and our plans for the future and how to get there together.

I don't disagree with the comment about the same team still contributing.  That wasn't the point of what I said.  As others pointed out in the thread, the level of transparency has changed, just as the openness of the code.  It's not as open as it once was.  The very "transparency" that drew people to Emby in the first place.

 

It's not just about Emby code but also the code of others that Emby itself uses like ffmpeg for example. Same with many of the codec and other property assets owned by others.

It isn't about taking the source away. It is about protecting it. It was being abused. People were not using it the way they should have. Forks were made to damage the Emby brand and take away monetization. There were efforts made to disparage Emby as this greedy big mean monster who just wants to take code others wrote and make a trillion dollars on the efforts of open source. Please.. There were issues in migrate to the new closed source model. And most things are still open that can be.

Sure, that's one way to look at it.  But when you have open source and encourage people to fork your code, the people changing things you did is part of it.  The bad comes with the good. That is the nature of open source itself.  Heck just look at ffmpeg and the turmoil it has went through and that's just one small part of Emby itself.

 

I pointed out early to just close source the Premiere features themselves so they couldn't be monkeyed with while leaving all non-premiere code open.  That would have been the best of all worlds and would have avoided JellyFin and the "hacking" that took place to un-premiere features.  No bad blood this way as the core would stay open, while additions and plugins could bring enhanced or new functionality and of course be charged for.  Emby started out as community software.  Many users spent hundreds/thousands of hours doing testing, writing feedback, making suggestions  doing PR, telling friends, doing support, etc.  The current state of Emby is in part owed to these very same people, not just current devs. That is something that often times seems forgotten.

 

As far as competition. Emby has really none. Plex is some BORG spaceship out to assimilate all media. It isn't just your media your way with plex. It is their agenda your media their way. They aren't really Emby competition. They serve a different customer. Emby is for the power user who wants more. More control. The customer who wants their media they way. Kodi is the closest competition to Emby. It also has a plugin to allow Emby to exist with it. Together. Together is the future. Kodi is more a partner than a competitor. It takes all kinds of fruit to make a fruit salad.

Exactly, so if JellyFin and Plex aren't really "competition" then who is Emby worried about running with ideas if Emby was more transparent?

 

I personally don't have an issue with Emby going closed source but would have done it differently (only premiere parts). But it's hard for some users to except the changing nature of Emby holding back what it's working on or going to work on when it used to do this and as already mentioned, probably contributed to it's success.  Communication is also one of the biggest gripes Plex users have as well so it's not unique here. :)

 

BTW, I don't think people want fine grained knowledge of things like exactly what part of code is being worked on. I think it's much more high level stuff people are asking about.  For example DVR enhancements and groups/categories for TV Channels have been requested by tons of people and a typical response is that it's planned for the future.  We all know that but what does "future" mean?  It was needed 3 years ago as much as it is needed today.

 

What I think people want to know with a "road map" is a rough overview of what is planned for the next major release and maybe the release after that.  Is the next major release going to have DVR enhancements or will it be the release or 3 after this one?  <-- That type of thing.

 

Personally I'd think this type of things would actually benefit Emby.  If someone was evaluating both Emby and Plex for family OTA/Cable DVR replacement to lower monthly expenses they may very well choose the package (all else equal) that has announced new improvements in the works.

 

Regardless of any change in "transparency", I just want the team to keep knocking things out of the ballpark with each release!  But with that said, I totally understand how knowing what will be in the works can help to plan things for admins.

  • Like 5
Link to comment
Share on other sites

mastrmind11

I think it could be as simple as a post every couple of weeks on what they're working on.  I'm a software engineer and we all meet every week for 5 mins to tell eachother what we're each working on.  I think that would be more than enough in this case.

  • Like 3
Link to comment
Share on other sites

miniliQuid

Honestly transparancy would be nice, but most companies aren't so I don't really see why Emby should be if they feel it can hurt them.

They have pretty good service which is most important.

 

Arguing about things like there ideas not being stolen or implemented faster are kinda silly.

This can always happen, and assuring them no one would is nonsense.

If a company who is doing something with servers decides to start working on home media server stuff they could easily steal ideas and if the company is big enough they can also easily beat emby to the punch.

 

Even though things may seem unlikely, it doesn't mean they are, or will stay like that.

 

That aside, any improvements on the feature request/work in progress area would be great :D

Link to comment
Share on other sites

  • 2 months later...
Richard Branches

I'm planning to subscribe to an Emby Premier monthly subscription just to help speed up my feature requests... is there something wrong by contributing to the project while I try to get what I want in return?

Link to comment
Share on other sites

  • 2 months later...

+1

I mean you guys must have a vague plan on what you want to work on for the next release, right?

 

Why not share that with us?

Link to comment
Share on other sites

+1

I mean you guys must have a vague plan on what you want to work on for the next release, right?

 

Why not share that with us?

 

You can see this as it develops in the beta releases and the discussion in that forum.  Any information beyond that would just be inaccurate fairly quickly.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...