Announcement

Collapse
No announcement yet.

Sponsor An Open Source Driver Dev For a $1 a Day???

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by l0b0 View Post
    The key would be targeting a small set of cards, possibly just a single series from one or two vendors. Maybe a system similar to the Humble Indie Bundle could work:
    1. Select your own payment, 0.01 upwards.
    2. Choose which vendors/series/cards the developers should focus on, with an additional option of "Any" to let the rest of the community choose.
    3. Choose which stats the developers should focus on, for example color fidelity, fast antialiasing, or simply FPS.
    4. Give extra incentives to those who pay more, either with stages (like Kickstarter) or using the average (like HIB).

    If the developers were able to boast something like 60 FPS in all the initial Steam for Linux releases on default settings on even a single card, that would be an enormous achievement, and it could be the wedge to finally level with Windows as a gaming platform.
    Sounds good to me, although too fine-grained options may be a showstopper
    in case not that many people are willing to give money.

    Maybe it would be even make sense to approach some bigger companies and
    ask them if they would also participate in a certain way like
    "Doubling any sponsored dollar."

    For instance, I'm thinking of companies like Canonical and VALVE.
    Both companies may profit directly but also positive press coverage shouldn't be underestimated IMHO.

    Comment


    • #17
      Project management

      I hope people agree that this is not a one-off project which is ever going to be "finished." To make the code future-proof, and to be able to offload smaller jobs to other developers, it is critical that the code is modular, testable and readable. The GSoC/EVoC method of hiring students works for short time, small budget projects, but to make this a long-term win there has to be top-notch developers in the core team.

      The location is another important aspect - It's orders of magnitude more convenient, accurate and productive to just show someone your monitor than to turn off the lights, take a good quality photo (or even video), and then write a concise, understandable summary of the situation to someone who might not get around to even checking it out for hours. Never mind having to negotiate what needs to be done for the others to reproduce the issue. Therefore the core team members should all be willing to relocate (location to be negotiated) to work there for an indeterminate amount of time (essentially as long as the funding lasts/is renewed).

      Comment


      • #18
        Originally posted by timothyja View Post
        Feedback:
        Anyway that’s the gist of my idea. I’m looking for feedback so that I can document more ideas around the subject and possibly put together a more complete proposal.
        This I'd fraggin' do in a heartbeat as long as I can be sure it's for general Drivers as well, and not just for Graphics, I'll need a Bigfoot (Qualcomm Atheros) Killer E2100 (powered by Linux on the Network Processing Unit) driver to get at least fundamental network connection going (My motherboard came with one built in and I have to use a secondary Network Card) to start with if needed be. And not only 1 dollar a month, I'll go as far as 25 USD if possible to fund driver efforts on Linux! I could even purchase a card if I knew about someone willing to do the deed since I myself don't have a clue how it all works.
        I'd also suggest to use some sort of Donation page where you can set the amount and use sliders to direct your fee towards certain types of categories like Network, Graphics, Sound, Input or what else could be. Something like Humble Bundle does it with Developers/Charity/Bundle tip.
        Oh and for Pete's sake, the only reason I haven't been able to fund most Kickstarters is because they do not support PayPal. I do not have a credit card and I never intend to get one, I also dislike having to create virtual ones or borrow from others.
        Last edited by dyrvere; 06-22-2012, 01:48 PM. Reason: Paypal

        Comment


        • #19
          Which system for micropayments do you guys suggest?
          Every system I've seen especially punishes small payments, and then a hefty percentage on top of that. Very discouraging.

          Comment


          • #20
            Yes, the idea is in the air. I'm in. Many others here suggested close ideas. So, it is in a very need, almost necessary now.

            Last time I suggested that:

            I think that it will be very useful. Also I think it should be like an open auction. Users could suggest ideas to developers and developers could offer a price and a project-time (time to implement the suggested feature); then users could choose a developer with an appropriate experience, price and project-time and send him (her, them) money.

            It is somehow an alternative way.

            But there are some constrains that should be on developers and their code. As l0b0 put it the code should be modular, testable and readable. For example, Nvidia can provide an opensource driver to their cards, but it can be unreadable, it can be intentially obfuscared. So, this "opensource" drivers will be unuseful and even harmful for community. Because there's acctually no difference between proprietary code and obfuscared code.

            Comment


            • #21
              Raising the money will probably be the easy bit.

              Working with Xorg would be good. try to grow it out of their EVoC, get some short term student projects, and the ones that are successful could be extended.

              Otherwise you might need to get a suitable company on board who can receive the money and pay somebody wage. It might be worth contacting companies like yorba, fluendo, collabora, codethink etc, and see if they would take on someone paid by a community fund.

              You could also contact the krita developers. They successfully raised $4000 to fund a student. http://linuxcrunch.com/content/krita...C4000-donation

              Comment


              • #22
                I have been thinking about doing that for years too!
                (But in my mind it was not Driver-only).

                There are plenty of very talented people that release awesome software everyday for nothing in return (thinking of Marek for example), maybe we could help them help us...
                Count me in!

                Comment


                • #23
                  Originally posted by blackiwid View Post
                  OMG First I thought great idea, after reading this that it would mainly come to the nouvou driver guys, I hate that idea, why would we sponsor guys to make a good driver for a company that blocks such stuff so good it can and not release any specs or something, then we help that company to get deals like that in china posted here somewhere, so we work very hard or pay money so that the company that sucks dont get punished for sucking on this area?
                  Just limit the nouveau sponsoring to gpus that aren't sold anymore.

                  Comment


                  • #24
                    Sounds like a brilliant idea. I'm a freelancing programmer that would gladly take on this challenge and I would definitely also donate to such a project.

                    Here are a few points that I think are important (based on my own experience):

                    1) Let the developers decide what to work on. Forcing it in a certain direction will lead to things being done in the wrong order or in the wrong way. The natural order of how to do things will likely be revealed when development has actually started.

                    2) Make the developers publicly report status and progress on a regular basis. Weekly would be preferred. Doesn't have to be much but people will want to know what their money is being spent on. Wolfire is doing a good job with this (blog.wolfire.com) on Overgrowth.

                    3) Don't put up deadlines. Deadlines should only be set by people who knows how long something is going to take. Nobody can say how long it takes to figure out a GPU. Milestones are fine as long as you don't put a date on them.

                    4) Make sure the work is documented. Writing documentation is boring, but in order for things to eventually work out it is required (see #5)

                    5) Allow failure. Sometimes things don't work out the way you intended. A developer might come to the realization that they are not the man/woman for the job. Allow resignation and don't make a big fuzz about it. With documentation the money is never wasted. That way a developer can easily say they're stuck and let someone else pick up where they left off. We don't want people sitting around doing nothing because they are stuck but still getting payed.

                    6) Prefer people with real world experience over students. This is because a fair amount of project planning will be required and the project will probably not be supervised like in school. Good understanding of how to plan and manage a project (even though you're the only one in it) is something you learn only after a few failures. Of course there are exceptions and students might be easier to find and employ.

                    7) Don't aim for the sky. Keep the expectations on a reasonable level. Wages will not likely be up to par with what the hardware manufacturers pay for their in-house developers. Because of that, we cannot expect to get the same level of expertise and speed of development.

                    8) Keep the figures public. Clearly state everything on a website. If that information isn't publicly available, we will get all kinds of rumors going.

                    9) Don't write long "contracts". Money needs to be secured for maybe a year or more, but don't promise more than a few months to a single developer. That will force them to make sure something is delivered back to the community on a regular basis. This will reduce the risk but perhaps make some devs look for something else. This is obviously something that needs to be tuned over time.

                    10) Make sure it is legal. Somebody needs to research this. Perhaps EFF and/or FSF could help with this.

                    These are the things that come to mind. I'm sure there are a lot more things that could be added to the list. Feel free to discuss.

                    Comment


                    • #25
                      Great idea - I'd chip in.

                      Great idea, I'd contribute a dollar a day.

                      Originally posted by dogsleg View Post
                      Yes, the idea is in the air. I'm in. Many others here suggested close ideas. So, it is in a very need, almost necessary now.

                      Last time I suggested that:

                      I think that it will be very useful. Also I think it should be like an open auction. Users could suggest ideas to developers and developers could offer a price and a project-time (time to implement the suggested feature); then users could choose a developer with an appropriate experience, price and project-time and send him (her, them) money.
                      I like this idea, but as suggested before we don't want to fragment the money too much so that it becomes insignificant. Perhaps we could do a variation on this like:

                      * Users donating can suggest development ideas of their own, or vote on existing ideas and would need the ability to log back in later and change their vote (incase a new and better idea comes up)
                      * Developers interested in working on the projects would submit a cost estimate p/month to work on the feature, and submit CVs inc. previous experience to be viewed in a list of developers on the site.
                      * After a certain amount of time passes, perhaps have a nominated day every 3 months or something, a selection round happens, and the top voted features are paired up somehow with a good developer (if more than one developer has submitted a cost estimate against a particular idea)... haven't thought this bit through - not sure who could choose a developer - perhaps another voting type arrangement?

                      Obviously this means that some features wouldn't make the cut and some people may not be happy with this, but it will at least get the most voted features implemented, and allow the end developer to be given enough money to comfortably complete the task. I know I'd still contribute happily for other features to be implemented that I didn't vote for, knowing that eventually the ones that I do care about will get there in the end as more people donate or other tasks finish.
                      Last edited by Kamikaze; 06-23-2012, 01:09 AM.

                      Comment


                      • #26
                        Excellent points, patrick.

                        Originally posted by patrik View Post
                        1) Let the developers decide what to work on. Forcing it in a certain direction will lead to things being done in the wrong order or in the wrong way. The natural order of how to do things will likely be revealed when development has actually started.
                        This might work if they do it Valve-style and with enough devs, but for crowd-sourcing I think a lot of them would want a definite list of work items before committing money to such a project. Verifiable goals or a test suite would be awesome.

                        Originally posted by patrik View Post
                        6) Prefer people with real world experience over students. This is because a fair amount of project planning will be required and the project will probably not be supervised like in school. Good understanding of how to plan and manage a project (even though you're the only one in it) is something you learn only after a few failures. Of course there are exceptions and students might be easier to find and employ.
                        Agreed, but students could be hired to do lots of tangential work, like developing test suites, writing informally about the project by sharing space with the devs for a while, acquiring test hardware, liaising with the vendors, making the web site for the project, etc.

                        Originally posted by patrik View Post
                        7) Don't aim for the sky. Keep the expectations on a reasonable level. Wages will not likely be up to par with what the hardware manufacturers pay for their in-house developers. Because of that, we cannot expect to get the same level of expertise and speed of development.
                        Originally posted by patrik View Post
                        9) Don't write long "contracts". Money needs to be secured for maybe a year or more, but don't promise more than a few months to a single developer. That will force them to make sure something is delivered back to the community on a regular basis. This will reduce the risk but perhaps make some devs look for something else. This is obviously something that needs to be tuned over time.
                        I don't know about the wages - If this project is to succeed, it will have to attract top notch devs, and I don't think they will be willing to relocate (see earlier post) just for a few months. Also, based on experience, for any complicated project (and this is sure to qualify) the productivity will be low for a long time (weeks~months) until all the aspects are familiar.

                        On the other hand, it seems like such a waste to use money to develop something which already exists, and which the hardware manufacturers could virtually at any time decide to open source. Maybe NVIDIA's recent loss (if it's actually real) may soften them to the idea of opening up...

                        Comment


                        • #27
                          I will contribute too!

                          Comment


                          • #28
                            It seems a "rewarding" system would solve some problems here.

                            For example I want the r600g driver do OpenGL 4.2. So I can create a pool "OpenGL 4.2 for r600g" and pay my money to it, probably also search for existing pools and contribute to them. Then the money just sits there on some bank account and accumulate interest.

                            Then some developer comes along, thinks "I can do that" and somehow attaches his/her name to the pool so that people know who is working on it. And once OpenGL 4.2 works on r600g he gets the money. Maybe you could get part of the money for a part of the work.
                            So there would have to be a committee that decides several things: Is it feasible to add another developer to a pool? If there are multiple developers in one pool how much work as each one done and so how much money does each one get? Maybe, is a developer trustworthy and skilled enaugh to get the money in advance?

                            So that committee should be trusted by everybody to make good decisions and developers and the committee should probably sign something legally binding that the developer does the work and then gets the money afterwards.

                            Comment


                            • #29
                              This would be great.

                              Currently I would be willing to sponsor.

                              Radeon 7000 series support. OpenGL 4.2 and OpenGL Stereo 3D
                              990FX series coreboot support.

                              For me coreboot needs a bit of donation love as well as the open source graphics drivers.

                              Comment


                              • #30
                                Originally posted by ChrisXY View Post
                                It seems a "rewarding" system would solve some problems here.

                                For example I want the r600g driver do OpenGL 4.2. So I can create a pool "OpenGL 4.2 for r600g" and pay my money to it, probably also search for existing pools and contribute to them. Then the money just sits there on some bank account and accumulate interest.

                                Then some developer comes along, thinks "I can do that" and somehow attaches his/her name to the pool so that people know who is working on it. And once OpenGL 4.2 works on r600g he gets the money. Maybe you could get part of the money for a part of the work.
                                Your idea is interesting, but I don't think it is feasible. It could work if you put up rewards for very small problems like bug fixing. But stuff like OpenGL 4.2 i just a too big time investment. I would say, start slow and hire a single dev to either work on AMD, Nvidia, PowerVR or similar but don't steer it much more than that. Sure, we need a goal (OpenGL 4.2 or whatever) but make sure the people giving donations understand that it is what we aim for. Not what will be delivered after XX months or so. I've been freelancing for 5 years and I would never put myself in a situation where I'm unsure when or if I get paid at all. Every hour spent must give something back or I cannot pay my rent. It's that simple.

                                So there would have to be a committee that decides several things: Is it feasible to add another developer to a pool? If there are multiple developers in one pool how much work as each one done and so how much money does each one get? Maybe, is a developer trustworthy and skilled enaugh to get the money in advance?

                                So that committee should be trusted by everybody to make good decisions and developers and the committee should probably sign something legally binding that the developer does the work and then gets the money afterwards.
                                A committee is a good idea. A few people with technical insight who can act as a barrier between the people donating and the developer. Those who donate might be screaming about OpenGL 4.2 but have no clue to what it really is about or how hard it is to implement. They just need it for game X or Y because it says so on the box.

                                Comment

                                Working...
                                X