Hi Otavio, You may not realize it, but the vast majority of the work I'm doing for customers is upstream from the start, and this include bug fixes, performance improvements, architectural fixes. The problem I think you have is the features you care mostly about (serial, parallel, smartcard) are those I have never got a request for by my customers. I'm not saying they aren't important, because they are, but none of my customers had those features on their priority list. I even bought a smartcard reader in hope of taking the time to fix smartcard redirection, but never got the time to really go in depth into it. I asked for help on how to simply configure a terminal server environment with smartcard auth a long time ago, and I still don't know how to do it. As for serial and parallel, I even bought old crappy printers on eBay to do some bug fixing. I did a few fixes but not enough, it's not fully working. Just figuring out how to test these features is a major blocker for a lot of developers who just aren't familiar with them. Combine that with being swamped with work from actual paying clients and it goes down the list of priorities. I'm sorry most of the customers come to me to improve and fix features which aren't on your priority list.
As for justifying myself, well, you're talking like all of this is easy and the only reason why it's not better is because we're not listening to your words of wisdom. I actually agree these are all very important points, but you don't seem to get the part where making it happen requires resources which we don't have, and the resources we do have are allocated are mostly put on what people pay me to work on. If people want better audio that doesn't skip, or better multimedia redirection, or crazy awesome fast RemoteFX, or RDP8 multitouch, or TS Gateway, or NLA, and these aren't part of the "serial, parallel, smartcard" list, then what should I do? Tell them to keep their money, find a day job which doesn't involve FreeRDP, and spend even less time contributing to this project? It's a general understanding that when you want something in an open source project that nobody else is already working on free, you can't expect someone to just take care of your specific problems in the same way one would get paid support but without paying for it. Free software doesn't imply free support. Most of the time free community support is really helpful but it depends on people's generosity and free time. You cannot *require* that they support you for free, that's the difference, even if a lot of the times they will. I hope I'm not being misunderstood here: we're happy to help to the best of our abilities, but it still doesn't mean we're free unpaid employees who have nothing to do but offer free support 24/7. Best regards, - Marc-Andre On Tue, Oct 22, 2013 at 12:58 PM, Otavio Salvador <ota...@ossystems.com.br>wrote: > On Tue, Oct 22, 2013 at 2:34 PM, Marc-André Moreau > <marcandre.mor...@gmail.com> wrote: > > I understand that this is constructive criticism, the issue is mostly > with > > the fact that one cannot realistically do what you suggest. Freezing > master > > is not an option, which is why we've made a stabilization branch: the > code > > there is simply stabilized over time with no breaking changes, while > master > > can remain what it's always been. As for listening to my customers, it's > > pretty much what I've been doing for the last 5 years: people pay for > > features and nobody wants to pay for tests, bug fixes which aren't > blockers > > to them, and general work which helps others but not them. In the end of > the > > day, what most people truly want is code that works for them and will > remain > > stable over time, they don't have the time to work in areas which doesn't > > directly benefit to them unless they are highly passionate about it and > can > > spend some of their free time doing extra work for fun. Let's just say I > > have done a VERY large amount of unpaid work on this project over the > years > > and cannot afford to do as much as I used to be. It's funny how certain > > features simply don't fix or complete themselves when I'm not working on > > them. Wishful thinking consistently fails me for some reason. > > Well this is how most Free Software projects work. In this case you > might start pushing your customers to pay for your time to stabilize > the new code for merging, as part of the project. > > > However, what you are getting is mostly an emotional reaction: if we > *had* > > the time to do more things right, then of course we would have frequent > > stable releases, more documentation, more API stability, more support, > more > > whatever you want. The problem is that there is only 24 hours in a day > and > > all that would be required in unpaid work is enough for a couple full > time > > employees. You can definitely ask that we do all of this and then say > later > > you've warned us we should have done it, it doesn't change the fact that > we > > simply don't have enough resources to do it and still have features to > > implement because our customers and community members need them for their > > specific projects. We've resisted most of RDP8 doing a lot of > stabilization > > work and optimization, and now we've got some catching up to do. With the > > new Microsoft RDP clients released, we have no choice but to move on to > at > > least starting portions of RDP8 and even RDP8.1 in master. This is pretty > > much why we could never freeze master, because there are too many people > who > > actually need to be working on the bleeding edge of FreeRDP. It's not a > > matter of choice, it's a matter of keeping up with the competition. If > they > > have it, then we've got to have it as well, and do it even better. > > We're not keeping up with competition. In competition SmartCard > redirection work; Serial work, Parallel Work. > > > Getting people to understand that open source doesn't mean there's a > whole > > team of unpaid employees at your disposal takes time, but as silly as it > > sounds, it's still true. As an example, a lot of the complaints you're > > having now, I've had them from developers at HP. Getting the stable-1.1 > > branch in place worked very well and they're using it and often > contributing > > bug fixes. I can say I am quite satisfied now how we operate with them. > > Maybe you should follow their example and start using the stable-1.1 > branch > > as well. If there are specific blocking issues that prevent you from > > upgrading and nobody is working on fixing them, then please allocate some > > resources on them. At least you have the assurance that the stable-1.1 is > > not a moving target, it's a stabilizing target. > > No; I am getting out of RDP business. > > I allocated a lot of resources for FreeRDP in past and this didn't pay > itself so it is a no-go for now at this moment. > > > So, to summarize: the stable-1.1 is what you're looking for. For blocking > > issues you might have that nobody is working on, we're not free > employees, > > which means you can either wait forever until somebody takes the time to > fix > > it for free or you can allocate resources to fix it. We will gladly merge > > your bug fixes, but we just don't have time to do free support 24/7 (and > > even if we had, there are too many issues to cover). The master branch is > > often used by people who need the bleeding edge of FreeRDP and can afford > > some occasional instability that is often fixed within a few days. I > guess > > you could compare master to debian sid and the stable branch to the > current > > debian stable release. You need debian stable, a lot of people need > debian > > sid, and you can't tell people who need debian sid that they need debian > > stable just like they can't tell you you need debian sid. > > Marc-Andre, seriously ... stop to justify things and claim there're no > way of doing it better. It always have better ways of doing things, it > is just a matter of finding it. > > I started this discussion to find better ways, not excuses. > > -- > Otavio Salvador O.S. Systems > http://www.ossystems.com.br http://code.ossystems.com.br > Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 > ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel
