[Home]OpenSource

MeatballWiki | RecentChanges | Random Page | Indices | Categories
http://opensource.org
http://opensource.mit.edu

Led by EricRaymond and others, a movement that split off from RichardStallman and the FreeSoftware movement during the late 1990s.

The Open Source Initiative is working to promote open software, especially among businesses. It created the Open Source Definition, a certification for software licenses. This definition has a lot of overlap with the GNU/FSF definition of Free Software, but is not identical. Bruce Perens wrote the original definition, modeled after the Debian Free Software Guidelines (DFSG), which were in turn heavily influenced by the Free Software Foundation (as exemplified by the name "Debian GNU/Linux").

(Most notably, the Apple Public Source License before version 2.0 is OSI-certified, but is not considered "Free" by the FSF.)

Though many of the principles are the same, Open Source has a pragmatic and economic emphasis, while Free Software emphasizes philosophy and ethics. OSI thinks that companies should release source code because it's good for business, while the FSF thinks that code should be open because it respects the freedom of authors and users.

For what it's worth, in the old days, all software was open source. It was unthinkable to not give out the source code when you shipped a machine. But since the days of the operating system as a commodity, things have changed. It's no surprise to find that BillGates? was (one of?) the main driving forces behind software licenses, not to say he was wrong. Ultimately, the answer is confused.

See also InformationWantsToBeFree.

References

While non-"free" open source licenses are often seen as "business-friendly", the FreeSoftwareFoundation's GPL has some advantages for businesses releasing code. The main advantage is the "viral" nature of the GPL, which limits the use of the code to GPL projects.

If the releasing company is careful, they can dual-license the code under the GPL and any other license. (All patches must be given to the releasing company, or the project may fork into GPL-only and proprietary forks.) In this case, the releasing company can offer non-GPL licenses, but all other companies using the code must release under GPL. This means that a competitor can't improve the GPL'ed work and re-release it under a closed license (which can happen under BSD-style licenses). A few companies use the dual-license model to support their GPL'ed software work with income from "GPL exemptions".

What's a BSD-style license?

This is a nutshell, simplistic, not-nearly-perfect description: A GPL-style license says that all derivative works are covered by the same license. Say, for example, you write something in C and is compiled by GCC, using GNU libraries. Because you used GNU intellectual property, licensed via the GPL, you are compelled/required to release the code (should you decide to release it) under a GPL license. In contrast, you can take something licensed under a BSD license, say "Mine!" and release it as you wish. Think of Mac OSX here, although I believe that SunOS? is largely BSD-derived, too. -- DaveJacoby

"Some people also assume that if they compile their program with the GNU C compiler (gcc), their program must be licensed under the terms of the GPL. This is not true." -- http://www.linuxjournal.com/node/1297/print

"Can I use GPL-covered editors such as GNU Emacs to develop non-free programs? Can I use GPL-covered tools such as GCC to compile them? Yes." -- http://fsf.org/licensing/licenses/gpl-faq.html

True. I thought about a better way to explain the issues. I couldn't find a good way. Feel free to change the text after "Say, for example," to come up with an issue where it works. For parallelism, I suppose "forking an open source project" would be better, and would work better with the BSD example. Apple didn't use Linux to make Darwin, did they? -- DaveJacoby

OpenSource advocates such as BrucePerens? and EricRaymond still like the GnuGeneralPublicLicense. They just accept more than that, which RichardStallman doesn't. EricRaymond says the main difference between OpenSource and FreeSoftware is the propaganda surrounding it. --DaveJacoby

I recently wrote this e-mail to an OpenSource developer (not truly FreeSoftware, I think) debating whether he should work for a closed source company:

The reason why I don't see a problem with closed sourced commercial development is that in the commercial environment closed source (small c) is the superior model. The Open Source (big O big S) "movement" has been a disaster for all but the superstars like Torvalds, Cox, Raymond, de Icaza, etc. It makes no sense to open up the central strategy of a company because by the basics of economics that is unthinkable. Companies are meant to compete. Successful competitors must withhold information from their opponents in order to succeed. See Chapter 11, The Art of War.

I see a fundamental disconnect between the Free Software (big F big S) Movement (really big M) and commercial enterprises. They don't mix fundamentally. Free software is about creating material for social causes. It's libre--without control. Commercial entities are necessarily about control. It's not correct in any way for a company to give away resources without expecting a commensurate return on investment. There is no commercial return in increasing the Social Good (big big S, slightly big G), at least in the short term. And certainly, often the net average long term return < the expenditure, which makes the move impossible (and illegal) for a corporation.

Truly, if you had real ethical issues with lining the bank accounts of a corporation, you shouldn't work for one. As an employee of a corporation, you are morally (small m, not ethically) responsible to represent the interests of that corporation while in its employ, especially to increase the investors return. Thus, you should create closed software if and only if (big if) it's best for the corporation.

On the other hand, if you wanted to volunteer your time for the social good, I encourage you to do that. In fact, I'd suggest that any responsible individual with sufficient surplus resources should do that. Well, must (small m) do that. One cannot be truly Happy (huge h) unless one is connected to his or her community (as one cannot be actualized until one is deeply socialized). -- SunirShah

The argument that it isn't good business to give away software carries best when one talks about a company that produces software for sale--it might not make sense for a development house to give away all their stuff.

However, as EricRaymond points out in TheCathedralAndTheBazaar, much

software (the claim is up to 90%!) in a corporate environment is not written for sale, but for in-house use. Even in this case, if the software embodies certain trade secrets, it might be unwise to make it Open Source.

On the other hand, if company-specific proprietary information can be modularized out of the design of the software (maybe not a bad idea in its own right) the company might be advised to release the code on a number of counts, not the least of which is the "many eyes make bugs shallow" effect in which someone else interested in solving the generic problem (instrument control, accountancy, whatever) catches an error that the original in-house team does not.

A company that relies on proprietary code, whether developed in house or purchase retail, risks its business being hostage to the people who develop that software. With Open Source software, having to rely on in-house or third-party contract developers to solve a problem no one else is interested in working on becomes a worst-case scenario, rather than the only option.

See also OpenSourceDefinition.

OpenSource for industry infrastructure

During Reengineering, SAP sold their enterprise system to many large companies as a way to rationalize and centralize their processes, and thus eliminate staff. However, as a single vender, SAP internally rationalized and centralized their process by making a more or less homogeneous system. Even though SAP is configurable to some extent, overall it imprints a certain way of looking at corporate organization.

But having the exact same process as your competitor eliminates your competitive edge. They increasingly offered the same products and services with the same price points. Thus, many industries collapsed into price wars, as they were offering the same quality of service. Mergers and acquisitions naturally came later to rationalize the industry sector, but this led to less competition and less variety for the consumer in the marketplace (cf. NoLogo).

Thus Businesses should not OpenSource their entire production system, or at least remand their entire process to third parties. They cease being businesses then; rather they become ghosts, shells, wrappers of another process. After all, being a business means doing something different. A successful business will always maintain a large portion of proprietary code (even if CopyLeft) that remains a TradeSecret since it represents a process that distinguishes it from others. This is also why SoftwarePatent?s must continue to exist.

Nevertheless, a lot of code a company must deal with is outside their core competency. Operating systems are not something the automotive industry wants to be building. Standards, platforms, utilities, algorithms--these are all commodities. They are most efficiently left to third parties.

Traditionally the third parties are proprietary software vendors. In fact, there remains a huge and growing market for third parties to take on commodity software and sell them to various sectors and industries. Thus, even if the auto industry is not an expert in real-time operating systems, Windriver can be. But of course, developers being developers, they want to control every bit that flows across the processor. Bashing your head into a broken third party software library is about as fun as bashing your head into a brick wall. Thus it can be very efficient, particularly for industry standards, to make this commodity software open source which is developed collectively by the industry players.

This open codebase in essence forms a (privately developed) "public infrastructure" on top of which individual companies can then specialize. As a bonus of making this infrastructure public, external third parties may then elect to become experts in this infrastructure code. Thus, if Nokia is better at selling cellphones, other companies are better at translating web pages into WAP. This can engenders innovation in the infrastructure of the industry, as experts in the infrastructure can take it further in ways that might be risky distractions for the main industry players. For instance, companies like Nortel and Cisco can make exotic new and faster switches; and yet these switches can still plug into the global telecom network.

For the most part, however, these industry standard OpenSource codebases belong to a controlling agency with a typically expensive membership fee. This brings up serious anti-trust concerns (to take the literal meaning) if new players cannot enter the market. If membership remains open to anyone who can pay, or the specification documents are made public even if influence in the process remains expensive, the pressure is alleviated.

Needless to say, FreeSoftware ideology does not fit well into this latter model, even if the GeneralPublicLicense does wonders. For a long period of time, RichardStallman spent more time going after Red Hat than Microsoft out of fear the for-profit Red Hat would screw the FreeSoftware movement. The anti-corporate animosity was palpable. But as Bob Young, co-founder of Red Hat, points out (see [1] c. June 2004) infrastructure projects are both necessary for commercial innovation and necessarily FreeSoftware.

Examples

One project that I am investigating is the VistaA health information system made by the Veterans Administration hospitals in the United States, which begin in the 1960s. Through Freedom of Information requests, they have open sourced their own software (!! think about that). They have now exported the software to other health systems around the world. What's most interesting about the project, however, is the grassroots, against the power social organization they have created around it to fight back against the administration, who was in favour of centralization. At one point the dispute was intense; Tom Munnecke told me their server room was a victim of arson! The developer community, the Hard Hats, have their own interesting stories of how they came together. I could say more, but this investigation for work, and so I'll leave it to you to read more about it yourself. -- SunirShah

OpenSource as a hobby

While business, governments, non-profits, and other sectors that make decisions and have money use OpenSource to further their ambitions, there is a large sector of people who do OpenSource (and particularly FreeSoftware) for personal joy. They do so as a hobby, even if motivated by an ideal--even of WorldDomination? as the Linux crowd jokes HaHaOnlySerious?. Though many of these people may in fact also be developing open source for pay, within the scope of OnlineCommunities, it's much more likely you will encounter people who are doing it only as a hobby.

OpenSource in the workplace requires different legal changes to create markets or to open markets that are artificially closed to the idea. Government laws forcing them to purchase software from national industry leaders may have to be struck; conversely, many suggest that health care information systems be made OpenSource if it is developed out of grant money or merely for the public good. OpenSource as a hobby does not need these affordances.

Rather, hobbyists merely need the protection of their right to tinker, as it is often called. They need the right to work "in the garage." They need to be protected from forces that want to close markets that should be available to those who just want to build things for the sake of building them.

Nonetheless, some who want "WorldDomination?" for FreeSoftware may be looking for legal changes to enable this. Changing the laws to force this is extreme, as it reduces market choice and thus constrains liberal democracy. Rather, if they want to compete on the open market outside the scope of a hobby, they are still protected by CopyrightLaw, and thus they are fully capable of doing so. The vast majority of people seeking "WorldDomination?" support this latter effort, and it's doubtful more than a small percentage of these really believe in WorldDomination? anyway. It's just a SuperordinateGoal to rally around.

OpenSource for science

OpenSource as correction

CopyrightLaw exists for the benefit of the publishers. Construction and proliferation of media resources require a duality of distribution channels and content productdion. Over the past 150 years, copyright terms have been consistently extended to maximize the profit of media and international IntellectualProperty treaties have allowed GlobalMedia? to penetrate and construct new markets. This has benefits and drawbacks. The largest benefit has been the construction of the infrastructure that leads to the Internet. The biggest drawback is markets that have not yet matured to the point where information has become a commodity. That is, markets that are still consumers of information in a "one-to-many" broadcast relationship. Consolidation of the GlobalMedia? has led to major concerns about who controls power in our world.

However, InformationWantsToBeFree, and the InternetProtocol has socialized distribution channels. Now that distribution costs are often fixed (i.e. flat-rate ISP) or at least so much cheaper than postage stamps that it's irrelevant, VanityPress-style production becomes economically bearable. This leads to a massive explosion in production by average people, away from the hierarchical structure of GlobalMedia?. In many ways this is ironic for the media industry. The Internet often runs on their wires. Since the hardware side of the industry is divorced from the content side more often than not, the hardware side grew to squish the content side. In another ironic twist, around the year 2000, many media companies tried to consolidate content and hardware.

Since IntellectualProperty laws have become disturbingly overpowerful, they have become a serious drain on the producing culture that we now enjoy once again. Human beings are naturally creative; it was only PrintCulture? that created the false notion of TheAuthor that could fix speech and mass distribute it unchanged. Rather, language is always a matter of renegotiation and reinterpretation. Excessive regulation of the renegotiation and reinterpretation of languistic expression is actually a limitation of FreeSpeech. This is why the FreeSoftware movement says it's free as in speech, not free as in beer (money).

That isn't to say that there is no benefit to CopyrightLaw. New media are always being created, and they need some method to capitalize their development. The printing press industry is constantly under fiscal pressure, and most reasonable people will recognize the continuing value of printed books despite the Internet. But if the laws to protect these push and pull (unilateral) content formats interfere with the OralCulture of a DigitalNetwork, they will need to be changed.

Therefore, OpenSource (and OpenContent) exist as a correction and a counterbalance to the IntellectualProperty laws. CopyLeft itself is an attempt to overhaul the entire IntellectualProperty system with a LethalText using technolibertarian methods. A better answer would be to renegotiate the structure of the IntellectualProperty system, but as long as this system is negotiated by bureaucrats in closed door meetings, it will only hang itself. That isn't to say one must become a gung ho copyleft fanatic, since copyleft by itself would be too extreme, but at least one should look at the complete competitive ecosystem of IntellectualProperty law. From the fight between copyleft and copyright, we will find new best practices that better fit the DigitalNetwork. Remember that the stronger the IntellectualProperty laws become, the stronger OpenSource licenses become (another irony). The ultimate best answer will likely be in a rebalance between control and commons.

OpenSource as education

OpenSource develops local skills in technology without a specific budgetary outlay for education. People learn more effectively by doing than being taught directly, and the OnlineCommunities that surround OpenSource help guide people learning coding by doing coding. For environments or jurisdictions without the resources to teach their citizens technology, as well as for citizens who are intrinsically motivated to learn, it is far more efficient to let people "tinker" in order to spur innovation.

Further, if education is concentrated in the North and the West, then the South and the East are left out of the whole of human knowledge. Publishing technical skills through OpenSource allow the rest of the world that has been traditionally left out of technical advancements to catch up with the richer parts of the world. Even within the richer countries, OpenSource allows technology transfer from large companies to small-to-medium enterprises (SMEs).

Employers also prefer people with real experience rather than people who are simply book learned. Working in OpenSource provides opportunities for individuals grow expertise in software development that may not otherwise be available from their current employers, schools, or unemployed situation. Young students are often the drivers behind most OpenSource projects simply to scratch their itch to develop something to try out and build their new skills.

See the related OpenSource as science.

Open Source and Feature Creep

Most software has atrocious FeatureKarma, and OpenSource for what it's worth is often much worse in that respect than proprietary software. That being said, when you purchase proprietary software, you don't really pay for the development and maintenance costs for all that feature creep, since it the costs are spread over a large number of customers via the licensing fees. You really do pay for bad feature karma when you have to train your users in using software that has far more features than required to solve the problems at hand.

If it costs nearly nothing to download software (once you find it), then it costs little to try it out. Either way, you don't pay much for using Software as-is. This encourages people to try new OpenSource software. Then again, in a professional setting this rarely happens. Most software products except for a few well-known desktop applications need extensive changes to adapt to business requirements. The benefit of open source is therefore mainly the low cost of giving it a try.

The caveat is InformationOverload. It does cost to try software out, and if there are a large number of OpenSource solutions, evaluators often feel overwhelmed. Further, there is always pressure to look at new software packages even after a decision has been made, since there might be no similar finality of a large investment that happens when you purchase software (not necessarily true though if the SwitchingCosts remain high). Finally, there is more pressure to feature creep rather than to simplify systems. At the moment there is very little software consulting going on the area of open source software, so the situation is not astonishing. It is not professionalized, yet.

Also note that there is an inherent tendency to not fork open source software. There is social pressure to keep SwitchingCost low -- therefore projects need a way to integrate a lot of different requirements. Instead of just one client, you may have a lot of stakeholders in the software. This is why a lot of open source software makes extensability (modules, scripting, customizing, skins) a top priority. And once it is easy to do, it will be done: Emacs, Linux, X, Apache -- all of them have tons of modules doing various things. If the architecture supports it, however, you will have lots of features without some of the feature creep costs: Complexity, debugging, and inter-dependencies can be kept low, even though there are lots of features.

Open Source to Mitigate Risk

Since open source software tends to be independent of the various copyright holders, only controlled by its license, there is little risk of the business plan behind the existing software being beyond your control. Even if the original supplier goes out of business, anybody can take the software up where it was left and continue developing it. Many professional, proprietary software products were hijacked by failing companies. The company goes down, and when its various assets are sold, the copyright to the software is sold as well -- to a new company that might have very different ideas about where it wants to take the softare. Customers of proprietary software have no possibility to choose a different path except to start from scratch.

Contributors: SunirShah, AlexSchroeder

To add to the constructive hopefully true things about OpenSource I've started to write above, I'm going after all the myths, pro or anti-FreeSoftware/OpenSource (aka FOSS). I'm getting really tired of it all. No one seems to understand what is going on, least of all me, and definitely not EricRaymond. Reading what I've said or written, I've fallen into trap after trap. These days, I try to follow the body, not the ball. That is, how the people organize, not the licenses, the code, or the crap people say.

I also think that the reason people are so fanatical about FOSS is that they don't really believe in it. Confident people are not very vehement. People who yell are most often trying to convince themselves. I wonder what is going through people's heads.

I saw EbenMoglen? speak in Berlin. His speech was trying to inspire the feeling that (to paraphrase) "we have already won; we will win; programmers can eat," which told me that they aren't winning and programmers aren't eating. I don't think he's the type to state the obvious. There is insecurity out there, and I think the myths aren't helping get to the truth, and that means the final result might be a world built on lies or untruths. That could be a worse result than the status quo.

Plus, I'd like to figure it out so I can eat. -- SunirShah

I think that it is dangerous to focus on the more outspoken evangelists out there. Just because an evangelist is nuts or chooses a particular rhetoric for a particular occasion that seems nuts, doesn't mean much (unless you want to understand the evangelist). Personally, I always focus on how the basic facts of my day job: We sell customized software to corporate clients. Our business model would not change if we used free software. That is a good starting point to think about software and food. -- AlexSchroeder

Myth? Given enough eyeballs, all bugs are shallow.

As EricRaymond writes in TheCathedralAndTheBazaar [2], this is Linus' Law.

In my experience, open source does not result in less buggy software. The phrase "With many eyes, all bugs are shallow," belies a major misunderstanding of collaborative projects. First, it presumes there are many eyes. Open source exists in an networked information age, which has an AttentionEconomy?, and so eyeballs very scarce. The majority of SourceForge projects are GhostTowns for a reason.

Second, the theory behind FreeSoftware, if not OpenSource, is hands can follow eyes. Many hands lead to feature creep as mentioned above--too many cooks in the kitchen. Most open source projects are very complex, with an explosion of features as everyone's ideas are incorporated. Trying to maintain consistency will often result in an explosion of forks. This poor FeatureKarma leads to a large number of bugs or a large outlay in development costs.

Further, this disrupts the StableBase that projects need to build on. Compare this to Windows. The joy of Windows programming until recently was that your software will run on every Windows machine, and if it fails, only nominal changes will need to be made (cf. [How Microsoft Lost the API War]). Microsoft maintained a StableBase to build upon. The hellish pain of autoconf and broken makefiles is a testament to how difficult it is to write software that ports easily across all the variants of BSD and Linux. And of course the UNIX file tree is a information organizational disaster.

Similarly, interoperability between open source projects is a nightmare. As the Rules of Open Source say, don't create a dependency on another project unless you are willing to take over that project. The solutions to this problem contradict the ideals of FreeSoftware (in perfectly reasonable ways). For instance, controlling access to the source tree or creating maintenance contracts with companies that RedHat? that prevent users from customizing their installation.

Also, I think many eyes can only find shallow bugs. The ConflictParadox is still stronger. The software may not crash, since those are the easiest bugs to fix, but open source projects tend to have very poor usability, which are also bugs. There are many sociological reasons for this, but the bugs that are much more complex than the "colour of the bike shed" do not get solved simply by having more voices. In fact, they may be exacerbated by the too many cooks.

What I do think results in less buggy software are better software development practices, which are for the most part better social organization practices. That people agree there is one canonical glibc or that people have come together to create strong, stable, popular distributions, and then social efforts have been made to standardize the Linux file tree across the major distributions. Of course, people don't agree there is one standard glibc, and there are a panoply of distributions. So OpenSource in the sense of Linux is more like the TowerOfBabel? than bug free.

Where EricRaymond is right is if the software author publishes their code but controls all changes to the mainstream codebase, then you might get the effect he describes, but it might often be better to just buy off-the-shelf proprietary software which is often higher quality than what's available to download as open source. At least you have the power of the money to effect changes, and all the changes are localized in one place by one group of people.

I'm saying follow the body, not the ball. It doesn't matter whether the software is behind some magic IntellectualProperty wall or out in the "open" or controlled by the FreeSoftwareFoundation or whatever. From the point of view of quality, it only matters who is working on the software, and how the people who are working on it are organized. -- SunirShah

There are aspects of "bug-free" that are orthogonal to "open-proprietary" while others are correlated. The most important aspect of creating BF software is to give the removal of bugs top priority (I do for example, Ward doesn't). To assign top priority is neither economical nor logical. It doesn't fit "proprietary", because you need to keep up a certain update and support pressure. It doesn't fit OpenSource, because you can't control priorities of independent developers, each one being free to have his own priorities. It doesn't even fit XP (Ward), because the removal of a bug is treated like a feature (the customer decides case-to-case when it is worth the effort). You must be a genius like Don Knuth or a bit crazy to give bugs top priority.

The second most important aspect is to have many users. No economic testing can reveal all the bugs. Here OS projects have their main advantage. It's easy to get users who post bug reports and feature requests. But if you have other ways to create a large user group, it's just as well. It's not a question of how many programmers eyes you have, because it's inefficient to let more than one or two code experts do the searching. It's the number of users and the diversity of their usage profiles that counts.

The third most important aspect is to have a consistent codebase. This is where OpenSource is worst, at least if it is really done as a community effort. I doubt that the successful projects are done that way. Only a core expert or group can keep consistency, which means that the larger community may contribute ideas, prototypes or snippets but is in effect powerless. That's the point where I think that ideological hype and reality differ the most. I think that the vision of an "open democratic core developer community" must be more or less an illusion. The chance that isolated technical communities (of such difficult people as software developers) can solve the ConstitutionalCrisis - we have been struggling with this for years - is extremely low.

I think very soon in the future, perhaps 3-5 years from now, participating people will not ask "what license?" but "what constitution?" primarily. -- HelmutLeitner

To your last point, that is what I am talking about when I say FairSoftware, and why I am now interested in building a knowledge repository for non-profit constitutions and accounting practices suitable for adopting by open net.collaborations. -- SunirShah

Three extra data points I thought up about why only shallow bugs are found. One reason perhaps why FOSS projects have a lower crash count and a better relationship "to the specification" is that users of FOSS are heavily weighted towards programmers, and programmers like to hunt down bugs when they are pissed off at software or bored or obsessive or what have you. Consumerware prioritizes in a different way because the end user group is different. However, once you leave the programmers' general level of proficiency, the ConflictParadox wins again. g++ was the worst C++ compiler around, despite being heavily used by programmer-users, and that prompted experts to come together to write egcs. MySQL doesn't accept changes from outside the core development group because most programmers have no idea how to write a database (and they also want to protect their profit model). -- SunirShah

OpenSource is more easily understood by Wiki:ConwaysLaw. The term OpenSource only looks at the product of the process (the source code), but it doesn't understand the process itself. The reason why developers feel compelled to release the source code is that they have to co-operate with developers they will never meet or know about. Or in other words, developers need the source code to the programs they are working on (that's a duh). When developing software for the Internet, this problem is very acute. It's impossible to develop a NetworkStandard such as SMTP without having some sort of open source reference implementation. However, once viewed in this frame, open source is no longer a zero or one proposition. One can release source code only to people one wants to include on the project, which is where the concept of CommunitySource? arises. Finally, within an open source project, one can often tell the actual power structure by the degree of modularization; in particular, one can tell the places of greatest interest, or why the groups of people have come together, by seeing what parts have been most fully developed and made most flexible and with the most backwards compatibility. -- SunirShah

Thoughts on OpenSource culture and wiki. The interesting tension within wiki is that to install it/ have it available, it needs to have one person as the administrator, even though that person is trusted, etc. it is still a tension within wiki. - MarkDilley (in conversation with BrianKerr?)

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: