The conference was prominately announced in the free gis community. If you are interested in free GIS I would suggest you join the freegis mailing list at freegis.org to keep on top of stuff.
> In other words, don't expect to find a complete > open source end-user application within your > lifetime.
The comment you quoted addresses the specific topic of cartographic map generation suitable for printing. I don't see any reason that several of the existing projects can't include respectible map production suitable for most GIS end users.
Furthermore, as noted, a serious cartographic production system could be implemented within a couple of years given an appropriate project to drive it.
> This is, alas, common in the open source world. > Everybody does their own toolkit that does 90% > of what other toolkits do, adds 10% of its own, > and assumes that the user is a person who gets > their jollies from writing code, not actually > using the application with production data.
Frankly, the report indicates that there is a great deal of sharing of supporting toolkits between the end user applications of various kinds. I think the open source world is much less to duplication of effort than the proprietary software world.
Also, many of the required applications do not require the end user to write code to do work.
There is still some way to go before any of the software packages is across-the-board competative with software offerings from ESRI or MapInfo but I would like to think that for end-user applications for much typical GIS work is coming together now. And many specific tasks are already filled better by open source tools in in this space, than by commercial tools.
In short, I feel your claim these are programmers tools, and not finished applications is unfair though I will conceed that none of these applications (with the possible exception of GRASS which has some ease of use issues) has as large a feature set as the major proprietary packages.
I have contributed to a few projects, and run
a number of projects myself. First as a
maintainer, let me list a few things that I
look for in someone wanting to contribute.
Does what the contributor is offering line up
reasonably well with my vision of the project? Sometimes people are looking to do something very different with my code than I intended... perhaps radically expanding the scope of a project for instance. I don't mind people doing this, but I tend to be unwilling to accept this all back into the core, thereby becoming somewhat responsible for it, preferring instead to just point off to
their work.
When supplying patches, does the contributor
explain clearly what the patch is supposed to accomplish?
Does the contributor seem competant?
Some situations where I didn't end up utilizing patches include:
Patches to get things building in environments that I don't use, and will have
trouble maintaining, like Borland C++. I can't
test the changes, and I can't maintain them.
Changes to fix a small/uncommon problem that
I fear might break lots of other stuff. This is especially true of "configure" changes that tend
to be very fragile, and that I often have trouble
being confident of the ramifications.
Library bindings for environments I don't use
(like python, tcl or perl bindings). I will often
dump these into a contrib source tree, but I don't
want to be responsible for them.
Contributed ideas that will be hard to
utilize. Some people think they have great ideas
but are not in a position to implement them and
think I will be thrilled to have their ideas. Well, they can offer them but don't expect me to
change the direction of my project to try them out.
I would like to note I have had very good
experiences submitting patches to the Mesa project. Patches I submitted with detailed explanations have been applied within a few days.
I have also had excellent submissions to many
of my projects, most notably to libtiff which
is of wide use and interest. In the case of
libtiff though, I have found some patches to
be difficult to apply because it is hard to be
sure the submitter has thought through all the
possible ramifications.
Finally, people have many things drawing at their
time, and it is often difficult to find the time
to review a patch and apply it to a project you
aren't actively work on at the time. So to the
extent possible, make it easy for the maintainer.
I would agree that implementation of OpenGIS
standards (before their web mapping work which
is widely supported) has been very disappointing.
However, even where not widely implement as
defined in the specification, early efforts like
"OpenGIS Simple Features" have had a broad
influence on the industry.
Furthermore, recent ESRI offerings (ArcGIS 8.1)
includes support for the Simple Features OLEDB
interface, and AutoCAD MapGuide supports SF OLEDB
as a data source.
I have made extensive use of the OGC "Well Known
Text" format for defining coordinate systems, and
have also implement some simple features work
as shown at:
While security may be an issue for some of
you, but biggest issue for me is long term
reliability. I want an email address that
will last for decades.
Features I am looking for are:
IMAP (or POP as second best) access. This
might just be used to pull email using
fetchmail.
Ability to forward by SMTP is desirable.
A reasonably professional looking address.
Fast, high availability email receipt and
relay.
Ability to hold substantial amounts of email
for a while if my home target system goes down.
I see some folks use the IEEE for this. They
offer what is essentially an aliasing service,
forwarding email from yourname@ieee.org to
your "current" email address.
I have made the fatal mistake of advertising my
@home.com address widely and now that I want to
change providers I feel I am going to be screwed.
I have a number of options for other addresses,
but I want one that I won't have to change for
a long time.
I don't want to establish something with a
provider that is likely to "change priorities"
in the future, or go bankrupt.
The OSSIM project will not address issues of satellite downlinks. However there is a interesting project under way where you can build an inexpensive downlink station for processing NOAA (weather satellite data). It is also hosted on www.remotesensing.org, and more information can be found at:
I think the question about distribution of the source has been adequately addressed. However, the point of the GPL requiring distribution of source is so that users can fix and improve the software they use.
My understanding is that your box will essentially be impossible to user upgrade since you don't provide user or root account access to the purchasers of your system. Is that right?
If so, source or no source, you have locked users into a position where they cannot use the source to solve problems with your box. I am not sure if this is legal or not under the GPL, but it is in direct contravention of the intent of the GPL.
I would encourage you to provide root access to the systems to purchasers that request it.
Based on my previous experience with companies being acquired, I think there is a good chance this move would result in damage to Cygnus. Some activities may be considered "non-strategic" to Red Hat and shut down. It is also typical for acquired companies to lose significant portions of the best staff as they see control of their destiny lost.
This is all part of the hurly burly of business, but given the stregically important role that Cygnus plays in the OpenSource world, most notably with GCC, we could all suffer.
This is actually a very good point. A project done on a bounty may become orphaned once completed. Of course this can happen to any OpenSource project, but it is moreso of a problem in this case, because it isn't obvious that the original development team loves the work enough to maintain it after finishing.
On the other hand, the original funding developer does have some impetous to do maintenance, and if done well, and provided as OpenSource anyone who is interested can take on maintenance.
Nevertheless, this is a risk worth taking. I think that vendors may also select for teams that they believe will maintain the product after initial completion.
A point of sale system for Walmart would generally give only a modest boost in productivity over whatever is in place. Having a good PoS system in place is important, but any given one won't be that much better than another.
PoS systems are also not very industry specific. In addition to Kmart, stores that don't compete to a significant degree with Walmart would benefit. A given competitor, like Kmart will generally not be positioned to adopt the system in the short term anyways.
However, you are right that some companies will be irked to see a competitor be able to take advantage of the work they funded. To make up for this it is often necessary to identify benefits for the original funding company to going OpenSource. Such as, they will benefit from improvements that others incorporate, or perhaps that the developers will work cheaper on an OpenSource solution.
I usually give a modest discount on OpenSource work, because it gives me a code base to work on for the next project I bid. And when I bid the next project I can charge a premium because I know the underlying technology better than anyone (I wrote it), and because I have the technology to leverage in doing the next customers project more cheaply than would normally be the case.
> o If there is a group project, who determines what percentage of the bounty each person gets?
This would be established by the prime contractor in their agreements with their subcontractors at project startup. If the subcontractors don't feel what they are offered is sufficient they can choose not to participate, or perhaps even try to come up with a proposal of their own.
> o What if there are disagreements after the project ends about who gets what money?
Generally the money would be paid by the vendor to the prime contractor who would pay the subcontractors. If there was a disagreement it could be worked out in a court based on the subcontracting agreement. If there was no formal subcontracting agreement (legally speaking) then the subcontractors had better trust their prime.
> o What if somebody contributes a non trivial amount of work but drops out halfway through because they disagree over some development issue?
Generally speaking they would be out of the money, but the prime contractor is still on the hook to make the project work.
These are all common issues for contractors working on multi-person, or multi-corporate projects. In generally project teams will form on the basis of mutual trust based on history, and/or formal (legal) agreements. I do lots of contracts small contracts without any legal agreement in place, on the basis that I trust other people, and that if they screw me it will do more damage to their reputation than it costs me in money.
There will be disagreements, and at sourceXchange I imagine one of the things a vendor would look at in the different proposals is if they think a project will hang together and complete successfully. Simpler proposals (less parties involved), and project teams with a strong reputation (for doing projects, not just as programming gods) will have an advantage.
I think that sourceXchange has side stepped some significant potential problems between vendor and project team by introducing the independent reviewer as a tiebreaker in terms of deciding if a project team has met a payment milestone. Furthermore, by indicating that vendors can terminate a contract after a disputed milestone they limit the vendors liability, and hence raise their willingness to try out these contracts.
First let me say that I don't expect the bounty system to handle large amounts of money (ie greater than 100million/year) in the near future. However, I think it may make a significant contribution to the OpenSource arena.
I think that Graydon raises some issues; however, I think most of them are addressed by sourceXchange.
Code Hiding:
Once a project has been assigned to a project team there is no reason to hide code. I do think that bounties based on the ``present us a working solution, and then we will pay'' with no continuing arrangements isn't going to go anywhere for the various reasons given.
Thus I would claim that bounty software (ala sourceXchange) can be developed in a community manner. However, you may encounter the situation where people don't feel like helping if they aren't getting paid since they figure the guy getting paid should do all the work.
Sullen/Bored:
Graydon suggests that developers doing bounty projects will be sullen and bored because they don't really want to be doing the project they are working on. I see the bounty system as a way of getting funding for projects in people's areas of interest. If you don't like what you will be doing, don't go for the contract. Generally I don't think the bounties will be lucrative, but rather will give a moderate level of income while working on a desirable project.
Technically Difficult:
I agree, but I think that sourceXchange has come up with some excellent techniques to deal with these problems. It remains to be seen how well they will work, but they can. Of course, they won't work for little fixes.
Another Approach:
I do agree that a mechanism for proposing projects that developers want to do could have value. I am not sure how it could be best handled though. Generally this works best for people well enough connected and known within an industry that they can present unsolicited proposals to a bunch of vendors that might be willing to back the project.
At one point Graydon talks about how the companies funding such project could then market the product and make their money back. I think this is a flawed view of why companies will fund such work. I think it will usually be to fill a gap in a larger product (for instance improved web server software for company that fundamentally sells web server hardware, or a library for translating different file formats). While the work should help the vendor --- usually by avoiding the cost of developing the software themselves when it is not a key piece of IP, I don't imagine these things will often be marketted by themselves.
In closing:
I mostly do projects within a narrow industry (geomatics data translation) that could fall under the bounty system. Most of the issues are the same as those Graydon points out, and yet I do fine. I think I (and others with less connections) could do better if there was an easier way of identifying projects that people want done.
It seems to me that a more practical, and less intrusive approach would be some sort of voluntary industry association.
It would be world wide, and member companies would agree to a set of principles related to usability, refund policy, and so forth. These companies would agree to the association having the power to levy fines up to some limit and in return the companies would be able to put a ``certification mark'' on their software packages.
Failure to live up to the principles would result in fines, and possibly revoking of permission to use the certification mark.
Of course, this would only have significance if customers showed a serious preference for software with the quality certification mark. Some (government/corporate) clients might make certification a requirement for RFPs.
Cost of the association would be covered by membership fees, and fines.
I think a point of contention in such an arrangement would be ensuring that the association was tough enough. If this was all initiated by software vendors, they would likely not want the association taking action except in the most severe circumstances. While the association would want to _appear_ consumer oriented, it would in fact be trying to act on behalf of it's members.
Perhaps the association could require a majority of board members be representatives from consumer organizations rather than industry folks.
This model is used at least somewhat successfully in many industries.
Folks... I contacted Tom Lane of the Indpendent JPEG Group and he says:
Nothing is happening within IJG; we are waiting to see what emerges from the ISO JPEG committee, and in particular whether it is (a) patent-free and (b) enough better than JPEG-1 to be worth a universal upgrade cycle.
On point (a), I have made my views quite clear to the JPEG committee, but I dunno whether they are listening. There will not be an IJG implementation of JPEG-2000 unless it is freely distributable and freely usable under essentially the same restrictions (ie, none to speak of) as our current code. Patent licenses are a show-stopper. But from what I've heard, all the proposals before the committee have some amount of patent encrustation.
On point (b), the poor track record of progressive JPEG has left me unenthused about pushing incompatible standards that offer only marginal or special-purpose improvements. JPEG-1 took the world by storm because it was an order of magnitude better than anything else available. Unless JPEG-2000 is that much better again, it faces at best an agonizing uphill fight; the world might be better off without the ensuing confusion. (I have not heard anything about what performance improvements they actually expect to get... but I am suspicious that we are going to see percentage points, not integer factors.)
The act of extracting a subregion of an image from an appropriate resolution level in a pyramid (or implied pyramid) can't be patented (effectively) since there is lots of prior art. However, the MrSID algorithms are tightly held, and I believe patented.
I have implemented a read for MrSID and there is nothing special about it's multi-resolution capability that you can't accomplish with a tiled and pyramided TIFF file (and I have). However the compression is great, and is taking the world by storm which is why we need a public and popular wavelet standard.
The Independent JPEG Group (IJG), of which Tom Lane is the most visible member, is responsible for the currently popular OSS JPEG implementation. See http://www.ijg.org for details.
I am wondering if the IJG is planning to (and has sufficient resources to) implement JPEG 2000 support quickly as the specification finalizes. Does anyone know? I asked Tom Lane about this indirectly a while ago, and he just pointed me to the www.jpeg.org web page.
The IJG did a great job on the current library, and I hope that they can do JPEG2000. I also think that if they need support (manpower/money) it would behoove the OSS comunity to provide it.
If for one agree that wavelet based approaches to compression are the future off lossy continuous tone compression. The MrSID technology for instance is great, but they hold a very tight hold on their proprietary technology. I think it is important to establish a popular, and public format and technology to fill this void or proprietary interests will damage OSS efforts.
Briefly, in my opinion Red Hat is about the best you could expect of a corporation. Their commitment to a fully free distribution is very laudable. Their significant commitment to new free development is great. They really seem to buy into our way of doing things.
On the other hand they are a corporation with investors and a board of directors. In the end this may may lead them to change as they work to maximize their shareholder value.
However, even at that, all we have to lose is that they won't be the Red Hat of old. I don't think it will be so hard to shift to other distributions in force if they try to screw us.
Myself, I would like to switch to Debian on general principle, but I am glad that Red Hat is out there, doing what they do.
As a community, I think we should take care to not demonize them too much in public.
Slashdot Mirror
hswerdfe,
The conference was prominately announced in the free gis community. If you are interested in free GIS I would suggest you join the freegis mailing list at freegis.org to keep on top of stuff.
> In other words, don't expect to find a complete
> open source end-user application within your
> lifetime.
The comment you quoted addresses the specific topic of cartographic map generation suitable for printing. I don't see any reason that several of the existing projects can't include respectible map production suitable for most GIS end users.
Furthermore, as noted, a serious cartographic production system could be implemented within a couple of years given an appropriate project to drive it.
> This is, alas, common in the open source world.
> Everybody does their own toolkit that does 90%
> of what other toolkits do, adds 10% of its own,
> and assumes that the user is a person who gets
> their jollies from writing code, not actually
> using the application with production data.
Frankly, the report indicates that there is a great deal of sharing of supporting toolkits between the end user applications of various kinds. I think the open source world is much less to duplication of effort than the proprietary software world.
Also, many of the required applications do not require the end user to write code to do work.
There is still some way to go before any of the software packages is across-the-board competative with software offerings from ESRI or MapInfo but I would like to think that for end-user applications for much typical GIS work is coming together now. And many specific tasks are already filled better by open source tools in in this space, than by commercial tools.
In short, I feel your claim these are programmers tools, and not finished applications is unfair though I will conceed that none of these applications (with the possible exception of GRASS which has some ease of use issues) has as large a feature set as the major proprietary packages.
Cygwin
... only 8, and it seems like enough.
Emacs
Mozilla
Visual Studio 6
Winamp
DLL Depends (depends.exe)
Acrobat Reader
VNC (client & server)
sheesh
- Does what the contributor is offering line up
reasonably well with my vision of the project? Sometimes people are looking to do something very different with my code than I intended
... perhaps radically expanding the scope of a project for instance. I don't mind people doing this, but I tend to be unwilling to accept this all back into the core, thereby becoming somewhat responsible for it, preferring instead to just point off to
their work.
- When supplying patches, does the contributor
explain clearly what the patch is supposed to accomplish?
- Does the contributor seem competant?
Some situations where I didn't end up utilizing patches include:- Patches to get things building in environments that I don't use, and will have
trouble maintaining, like Borland C++. I can't
test the changes, and I can't maintain them.
- Changes to fix a small/uncommon problem that
I fear might break lots of other stuff. This is especially true of "configure" changes that tend
to be very fragile, and that I often have trouble
being confident of the ramifications.
- Library bindings for environments I don't use
(like python, tcl or perl bindings). I will often
dump these into a contrib source tree, but I don't
want to be responsible for them.
- Contributed ideas that will be hard to
utilize. Some people think they have great ideas
but are not in a position to implement them and
think I will be thrilled to have their ideas. Well, they can offer them but don't expect me to
change the direction of my project to try them out.
I would like to note I have had very good experiences submitting patches to the Mesa project. Patches I submitted with detailed explanations have been applied within a few days.I have also had excellent submissions to many of my projects, most notably to libtiff which is of wide use and interest. In the case of libtiff though, I have found some patches to be difficult to apply because it is hard to be sure the submitter has thought through all the possible ramifications.
Finally, people have many things drawing at their time, and it is often difficult to find the time to review a patch and apply it to a project you aren't actively work on at the time. So to the extent possible, make it easy for the maintainer.
However, even where not widely implement as defined in the specification, early efforts like "OpenGIS Simple Features" have had a broad influence on the industry.
Furthermore, recent ESRI offerings (ArcGIS 8.1) includes support for the Simple Features OLEDB interface, and AutoCAD MapGuide supports SF OLEDB as a data source.
I have made extensive use of the OGC "Well Known Text" format for defining coordinate systems, and have also implement some simple features work as shown at:
http://gdal.velocet.ca/projects/opengis/
While security may be an issue for some of you, but biggest issue for me is long term reliability. I want an email address that will last for decades.
Features I am looking for are:
- IMAP (or POP as second best) access. This
might just be used to pull email using
fetchmail.
- Ability to forward by SMTP is desirable.
- A reasonably professional looking address.
- Fast, high availability email receipt and
relay.
- Ability to hold substantial amounts of email
for a while if my home target system goes down.
I see some folks use the IEEE for this. They offer what is essentially an aliasing service, forwarding email from yourname@ieee.org to your "current" email address.I have made the fatal mistake of advertising my @home.com address widely and now that I want to change providers I feel I am going to be screwed. I have a number of options for other addresses, but I want one that I won't have to change for a long time.
I don't want to establish something with a provider that is likely to "change priorities" in the future, or go bankrupt.
http://www.tmcsys.com/ssi/ssifaq.html I am not sure how evolved this is yet.
My understanding is that your box will essentially be impossible to user upgrade since you don't provide user or root account access to the purchasers of your system. Is that right?
If so, source or no source, you have locked users into a position where they cannot use the source to solve problems with your box. I am not sure if this is legal or not under the GPL, but it is in direct contravention of the intent of the GPL.
I would encourage you to provide root access to the systems to purchasers that request it.
Folks,
Based on my previous experience with companies
being acquired, I think there is a good chance
this move would result in damage to Cygnus. Some
activities may be considered "non-strategic" to
Red Hat and shut down. It is also typical for
acquired companies to lose significant portions
of the best staff as they see control of their
destiny lost.
This is all part of the hurly burly of business,
but given the stregically important role that
Cygnus plays in the OpenSource world, most notably
with GCC, we could all suffer.
This is actually a very good point. A project done on a bounty may become orphaned once completed. Of course this can happen to any OpenSource project, but it is moreso of a problem in this case, because it isn't obvious that the original development team loves the work enough to maintain it after finishing.
On the other hand, the original funding developer does have some impetous to do maintenance, and if done well, and provided as OpenSource anyone who is interested can take on maintenance.
Nevertheless, this is a risk worth taking. I think that vendors may also select for teams that they believe will maintain the product after initial completion.
A point of sale system for Walmart would generally give only a modest boost in productivity over whatever is in place. Having a good PoS system in place is important, but any given one won't be that much better than another.
PoS systems are also not very industry specific. In addition to Kmart, stores that don't compete to a significant degree with Walmart would benefit. A given competitor, like Kmart will generally not be positioned to adopt the system in the short term anyways.
However, you are right that some companies will be irked to see a competitor be able to take advantage of the work they funded. To make up for this it is often necessary to identify benefits for the original funding company to going OpenSource. Such as, they will benefit from improvements that others incorporate, or perhaps that the developers will work cheaper on an OpenSource solution.
I usually give a modest discount on OpenSource work, because it gives me a code base to work on for the next project I bid. And when I bid the next project I can charge a premium because I know the underlying technology better than anyone (I wrote it), and because I have the technology to leverage in doing the next customers project more cheaply than would normally be the case.
> o If there is a group project, who determines what percentage of the bounty each person gets?
This would be established by the prime contractor in their agreements with their subcontractors at project startup. If the subcontractors don't feel what they are offered is sufficient they can choose not to participate, or perhaps even try to come up with a proposal of their own.
> o What if there are disagreements after the project ends about who gets what money?
Generally the money would be paid by the vendor to the prime contractor who would pay the subcontractors. If there was a disagreement it could be worked out in a court based on the subcontracting agreement. If there was no formal subcontracting agreement (legally speaking) then the subcontractors had better trust their prime.
> o What if somebody contributes a non trivial amount of work but drops out halfway through because they disagree over some development issue?
Generally speaking they would be out of the money, but the prime contractor is still on the hook to make the project work.
These are all common issues for contractors working on multi-person, or multi-corporate projects. In generally project teams will form on the basis of mutual trust based on history, and/or formal (legal) agreements. I do lots of contracts small contracts without any legal agreement in place, on the basis that I trust other people, and that if they screw me it will do more damage to their reputation than it costs me in money.
There will be disagreements, and at sourceXchange I imagine one of the things a vendor would look at in the different proposals is if they think a project will hang together and complete successfully. Simpler proposals (less parties involved), and project teams with a strong reputation (for doing projects, not just as programming gods) will have an advantage.
I think that sourceXchange has side stepped some significant potential problems between vendor and project team by introducing the independent reviewer as a tiebreaker in terms of deciding if a project team has met a payment milestone. Furthermore, by indicating that vendors can terminate a contract after a disputed milestone they limit the vendors liability, and hence raise their willingness to try out these contracts.
First let me say that I don't expect the bounty system to handle large amounts of money (ie greater than 100million/year) in the near future. However, I think it may make a significant contribution to the OpenSource arena.
I think that Graydon raises some issues; however, I think most of them are addressed by sourceXchange.
Code Hiding:
Once a project has been assigned to a project team there is no reason to hide code. I do think that bounties based on the ``present us a working solution, and then we will pay'' with no continuing arrangements isn't going to go anywhere for the various reasons given.
Thus I would claim that bounty software (ala sourceXchange) can be developed in a community manner. However, you may encounter the situation where people don't feel like helping if they aren't getting paid since they figure the guy getting paid should do all the work.
Sullen/Bored:
Graydon suggests that developers doing bounty projects will be sullen and bored because they don't really want to be doing the project they are working on. I see the bounty system as a way of getting funding for projects in people's areas of interest. If you don't like what you will be doing, don't go for the contract. Generally I don't think the bounties will be lucrative, but rather will give a moderate level of income while working on a desirable project.
Technically Difficult:
I agree, but I think that sourceXchange has come up with some excellent techniques to deal with these problems. It remains to be seen how well they will work, but they can. Of course, they won't work for little fixes.
Another Approach:
I do agree that a mechanism for proposing projects that developers want to do could have value. I am not sure how it could be best handled though. Generally this works best for people well enough connected and known within an industry that they can present unsolicited proposals to a bunch of vendors that might be willing to back the project.
At one point Graydon talks about how the companies funding such project could then market the product and make their money back. I think this is a flawed view of why companies will fund such work. I think it will usually be to fill a gap in a larger product (for instance improved web server software for company that fundamentally sells web server hardware, or a library for translating different file formats). While the work should help the vendor --- usually by avoiding the cost of developing the software themselves when it is not a key piece of IP, I don't imagine these things will often be marketted by themselves.
In closing:
I mostly do projects within a narrow industry (geomatics data translation) that could fall under the bounty system. Most of the issues are the same as those Graydon points out, and yet I do fine. I think I (and others with less connections) could do better if there was an easier way of identifying projects that people want done.
I wish sourceXchange well.
It seems to me that a more practical, and less intrusive approach would be some sort of voluntary industry association.
It would be world wide, and member companies would agree to a set of principles related to usability, refund policy, and so forth. These companies would agree to the association having the power to levy fines up to some limit and in return the companies would be able to put a ``certification mark'' on their software packages.
Failure to live up to the principles would result in fines, and possibly revoking of permission to use the certification mark.
Of course, this would only have significance if customers showed a serious preference for software with the quality certification mark. Some (government/corporate) clients might make certification a requirement for RFPs.
Cost of the association would be covered by membership fees, and fines.
I think a point of contention in such an arrangement would be ensuring that the association was tough enough. If this was all initiated by software vendors, they would likely not want the association taking action except in the most severe circumstances. While the association would want to _appear_ consumer oriented, it would in fact be trying to act on behalf of it's members.
Perhaps the association could require a majority of board members be representatives from consumer organizations rather than industry folks.
This model is used at least somewhat successfully in many industries.
Nothing is happening within IJG; we are waiting to see what emerges from the ISO JPEG committee, and in particular whether it is (a) patent-free and (b) enough better than JPEG-1 to be worth a universal upgrade cycle.
On point (a), I have made my views quite clear to the JPEG committee, but I dunno whether they are listening. There will not be an IJG implementation of JPEG-2000 unless it is freely distributable and freely usable under essentially the same restrictions (ie, none to speak of) as our current code. Patent licenses are a show-stopper. But from what I've heard, all the proposals before the committee have some amount of patent encrustation.
On point (b), the poor track record of progressive JPEG has left me unenthused about pushing incompatible standards that offer only marginal or special-purpose improvements. JPEG-1 took the world by storm because it was an order of magnitude better than anything else available. Unless JPEG-2000 is that much better again, it faces at best an agonizing uphill fight; the world might be better off without the ensuing confusion. (I have not heard anything about what performance improvements they actually expect to get ... but I am suspicious that we are going to see percentage points, not integer factors.)
So, I'm waiting and watching.
The act of extracting a subregion of an image from an appropriate resolution level in a pyramid (or implied pyramid) can't be patented (effectively) since there is lots of prior art. However, the MrSID algorithms are tightly held, and I believe patented.
I have implemented a read for MrSID and there is nothing special about it's multi-resolution capability that you can't accomplish with a tiled and pyramided TIFF file (and I have). However the compression is great, and is taking the world by storm which is why we need a public and popular wavelet standard.
More information on JPEG 2000 can be found at http://www.jpeg.org.
I am wondering if the IJG is planning to (and has sufficient resources to) implement JPEG 2000 support quickly as the specification finalizes. Does anyone know? I asked Tom Lane about this indirectly a while ago, and he just pointed me to the www.jpeg.org web page.
The IJG did a great job on the current library, and I hope that they can do JPEG2000. I also think that if they need support (manpower/money) it would behoove the OSS comunity to provide it.
If for one agree that wavelet based approaches to compression are the future off lossy continuous tone compression. The MrSID technology for instance is great, but they hold a very tight hold on their proprietary technology. I think it is important to establish a popular, and public format and technology to fill this void or proprietary interests will damage OSS efforts.
Briefly, in my opinion Red Hat is about the best
you could expect of a corporation. Their
commitment to a fully free distribution is very laudable. Their significant commitment to new free development is great. They really seem to buy into our way of doing things.
On the other hand they are a corporation with investors and a board of directors. In the end this may may lead them to change as they work to
maximize their shareholder value.
However, even at that, all we have to lose is that they won't be the Red Hat of old. I don't think it will be so hard to shift to other distributions in force if they try to screw us.
Myself, I would like to switch to Debian on general principle, but I am glad that Red Hat is out there, doing what they do.
As a community, I think we should take care to not demonize them too much in public.