<div class="gmail_quote">On Wed, Oct 10, 2012 at 10:03 PM, Michael T. Dean <span dir="ltr"><<a href="mailto:mtdean@thirdcontact.com" target="_blank">mtdean@thirdcontact.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
"in spite of users complaining about it, then it must not be important enough to any of those who are doing development to warrant their attention."<br></blockquote></div><br>This is one of the things that can be a problem with open source. Importance has nothing to do with if something gets fixed or not, it all depends on if a developer likes that part of the project. As long as nothing segfaults or is critical in some other way.<br>
<br>Either you have a project with developers that work with the things they like and think are fun, i totally understand that. But then you need a lot of developers that think different things is fun. And you get a problem when one developer has put down much time on some features, and that developer in one way or another stops to develop. If there isn't anyone else that think those features are fun, nothing will happen when it needs improvements or bug fixing. For example like LiveTV that no one, or few, of the developers use or think is fun. And i would think it is very complex and hard to understand that code also which doesn't help for someone to learn it. I would call this a project by developers for developers. Often hard to configure and setup, but powerful when you take the time.<br>
<br>The other possibility is a project run by developers that develop because they love the project. Maybe they don't like every part of it, but because they like the project they want everything to be good and do things for the project and not for them selves. In the end everyone will benefit from this, and they know that. A project by developers for everyone. Often easy to use and setup, because the developers in some way develop for the end users.<br>
<br>Both ways work, but the first one needs more developers when the project gets big. The second way works all the time but takes more time with only a few developers when the project gets big. Myth is big with too few developers not thinking all the parts of Myth is fun.<br>
<br>The first way you could get a lot of users complaining, but since no one cares or have the time to address the issues the users have, you get what you have in MythTV. I think the developers should consider to remove the parts that no one likes to work with. I love LiveTV and use it a lot. But since no one else do, there are problems with LiveTV, getting me to look at other solutions. Does it really matter if people look at other solutions because LiveTV has bugs, or because LiveTV is not a part of MythTV at all? Same same in the end. If you choose to only do thing that developers like and have the time for, do that and do it good, remove the other parts. Otherwise i think it will be such much bad blood in the end that the developers even don't want to develop the parts they like. It would be sad to see Myth die, because in many ways it is the most powerful solution you can find. Do what you think is fun, if fun is the main force driving you forward, and remove the other parts. Maybe one day someone will come by that think those parts are fun, then include them again.<br>
<br>Maybe the developers should figure out what the goal with MythTV is? And then write it on the main web page, so that users don't expect things they won't get. If you only want do to things you like, write that. So the users understands that not all parts of MythTV will work as good as some other parts. Depending on that no one likes those parts. Be honest, nothing wrong with that.<br>