Thursday, March 01, 2012

Big Toilet is Watching You

"Toto, short for Tōyō Tōki (Oriental Ceramics), is a Japanese toilet manufacturer that designed the Intelligence Toilet II. This toilet analyzes our excreta and records data like weight, BMI, blood pressure, and blood sugar levels. It even has a sample catcher in the bowl to obtain urine samples, which for instance can used to predict pregnancies. This information is then sent to your PC, showing your vital health stats."

It would be a simple effort to share this information with your doctor and even with your health insurer. Imagine this, "You just went to the toilet and that triggered an automatic email informing you that your health insurance went up."

The future is here; resistance is futile. And, maybe, just maybe, there are monsters in the toilets after all.

News link

Good (Protocol) Design Lasts Forever

Want to learn the technology that's in the center of the Web 2.0 storm?  It's a simple thing like REST that created the synergy that allows different web services to have the multiplication effect.


Still trying to decode above diagram? No need, that's way too complicated, to learn REST, just go back to the original design of HTTP, and stick to it. In case you also need a language to code http easily,  here is a javascript http hello world.

A powerful design, like HTTP, last forever. And the beautify is, it's as simple as you could get/understand.

Wednesday, February 29, 2012

Most "Productive" Cities In The World?

Based on a just released Brooking Institution report and this CNBC report. To be exact, they are comparing per-capita GDP and changes in employment data from 2010 to 2011 among the 200 largest metropolitan areas of the world.

Please download the full report here (5MB) , it's very good.

These are the metro areas that surprised me in a nice way: Hartford and Buffalo. Both cities are a little bit run-down. But I guess the surrounding wealthy towns more than make up for it.

Didn't know Chinese political powerhouse Beijing is almost at the bottom (187/200) still. Indian outsourcing capital of the world Mumbai is second to the bottom, and Cairo, knowing it's poor, is at the very bottom? 

Uncle Sam wants you to rent out its foreclosed homes

Fannie Mae will offer up nearly 2,500 distressed properties in eight locations to investors who are willing to buy them in bulk and rent them out for a set number of years.

Does Uncle Sam favor the rich? Why not just release the distressed properties into the open market, and let the little investors like you and me to "share the prosperity"?

This reminds me of President Obama's big tax break for big companies but actually raising tax for small business owners (so-called the rich who makes $200K a year)

Talking about Crony Capitalism!

Thursday, February 23, 2012

Get a ticket for ... Speed Trading?

"WASHINGTON—The Securities and Exchange Commission is looking to curb high-frequency traders' huge influence on stock trading and is considering charging fees for the myriad buy and sell orders that are later canceled, among other options." from WSJ


What's Next? You cannot put on a pretty dresses, as they might give you an unfair advantage in the "dating game"? How about you are not allowed to read extra books, do extra exercise, as they might give you an edge on test-taking, and sport events?

What's wrong with paying extra money or effort, or starting earlier than your peers, to gain an edge?

Enough already!

Thursday, October 05, 2006



許多人都有朋友"在華爾街搞電腦/玩數學/作交易", 有更多人對"華爾街"(泛指金融業)的工作性質感到好奇. 就連許多在華爾街工作很久的人也不清楚每天跟他一起吃中飯的人在作什麼. 我嚐試著將我所知道的整理出來. 以後如有時間會更深入的針對每一項詳加闡述

Here are the jobs in broader financial quant/engineering/technology field

Finance & Banking, Services & Support

Analysis, Strategic Planning & Corp. Development
Financial Data & Software Services
Financial Products & Services Marketing
Compliance/Regulatory Reporting
Financial Consulting & Advisory Services
Private/Consumer Banking

Corporate Credit & Commercial Lending

Corporate & Counterparty Credit Risk Management
Credit Analysis
Loans/Credit Portfolio Analytics

Quantitative Finance, Financial Engineering

Derivatives Pricing/Research & Modeling
Quantitative F.I. Modeling & Research
Quantitative Risk Management
Quantitative Equity Research & Modeling
MBS/ABS Research; Prepayment & Default Modeling
Quantitative Portfolio Mgt., Investment Analytics
Analytical Trading "Quants"
Corporate Credit Research & Modeling
FX & Commodities "Quants"


Risk Management

Market Risk Management
Corporate & Counterparty Credit Risk Management
Risk Management Consulting & Advisory
Enterprise & Operations Risk
Energy/Utilities Risk Management
Risk Management Systems & Technology


Equity Research/Industry Analysis
Equity Arbitrage, Trading & Sales
Equity Portfolio Management
Equity Systems & Technology

Fixed Income Securities

Quantitative F.I. Modeling & Research
Fixed Income Research
Fixed Income Sales & Trading
Fixed Income Portfolio Management
MBS/ABS Research; Prepayment & Default Modeling
MBS/ABS Structuring & Securitization
CBO/CLO/CDO Structuring & Securitization
Fixed Income Systems & Technologies

Derivatives/Futures/FX & Structured Transactions

Interest Rate Derivatives
Equity Derivatives
Structured Transactions, Credit & Insurance Derivatives
Foreign Exchange, Futures & Commodities
FX & Commodities "Quants"
Derivatives Systems & Technology

Corporate/Structured Finance & Securitization

CBO/CLO/CDO Structuring & Securitization
Mortgage Banking & Consumer Finance
Corporate Finance, M&A and Syndication

Portfolio Management

Equity Portfolio Management (Value Investing, Long/Short, Index, Vol, etc)
Fixed Income Portfolio Management
Loans/Credit Portfolio Analytics
Alternative Investments, Hedge Funds
Fund Of Fund, Endowment Funds
Administration, Operations, Trust & Safekeeping
Portfolio Management Systems & Technology

Financial Industry Applications & Systems

Quantitative Systems Development
Derivatives Systems & Technology
Fixed Income Systems & Technology
Equity Systems & Technology
Portfolio Management Systems & Technology
Risk Management Systems & Technology
Accounting Systems
Security Lending/Repo Systems

Computer Systems & Technology

System Integration
Financial Protocols (FIX, SWIFT, etc)
Quantitative Systems Development
Project Management
Systems Analysis, Design & Architecture
Business Analysis, Knowledge Engineering, User Liaison
Statistical Programming
Database Technologies (VLDB, High Throughput)
Messaging Technologies (TIBCO, Bus, etc)
Web Development & Technology
Object Oriented Programming
Systems/Network Administration
Security Technologies
Application Support
Systems Support (desktop, server)
Quality Assurance
Help Desk


MBS/ABS Structuring & Securitization
CBO/CLO/CDO Structuring & Securitization
Mortgage Banking & Consumer Finance


Communication Skill 溝通能力

Express yourself. 妳要有完整表達自己想法的能力. 事情不是只有成功或失敗, there are many inbetween,
Be able to read the dynamics. 知道週遭環境錯綜複雜的人際關係, 才會做出最適化的判斷
Keep everyone in the loop. 充分告知每個相關人員project的進度及遇到的任何困難. 責任變成由許多人共同承擔

Problem Solving

Is particularly important in a complex system (like finance).
能夠用 Common Sense + 專業技巧 + 經驗 快速合理的解決問題
When stakes are high and time is little.耐壓冷靜可靠的處理每個問題

Bryant Park in the summer

Domain Knowledge

不管你的部門/公司的業務是什麼,我只能說 : 不計代價,把它搞懂!

Technical Skills

數學永遠是最重要的東西: 統計,數值方法,微分,演算法
寫程式功力要紮實: 邏輯清楚,細心,動作快, also keep yourself updated

Magic Kingdom

Attitude 工作態度

Eager Learner 表現出對任何事物都有強烈的學習態度
Team Player 你在團隊裡面應有 1+1>2 的效果
Attention to Detail 對細節的重視
Pay Your Due 不要一學會一樣東西就想跳槽或換部門. 1. doesn't look good on the resume 2. 練功不夠

Management Skills

Project Management 對每一件事掌握節奏以及協調進度直到完成
Clients Management 精確掌握客戶(每個人對妳有所求的都是妳的客戶)的期望
Team Cheerleader 鼓舞士氣

川普, 小心了!

you are fired!


我想如果你錯過了變成 Bill Gates, Donald Trump 或 Sam Walton 的大好機會, 至少你可以從小培養你的子女下列特質或創造出以下環境, 讓他們 have a shot at it.

There are many factors, including genetics, that can help an entrepreneur


Posted Monday, August 21, 2006

What attributes suggest someone's a good candidate to start their own business?
A college degree doesn't hurt, though dropping out didn't stop Bill Gates from launching the world's biggest software maker. Being rich would solve the problem of startup financing, yet Sam Walton got his start in business on not much more than a wing and a prayer.

There are no definitive answers, but the entrepreneurs, private investors and academics suggested these experiences, traits and skills:

Childhood experience 兒時經驗
You didn't rely on allowances and other handouts from your parents for spending money when you were young. You set up a weekend lawn-mowing business and hired friends to work for you. Or you franchised your lawn-mowing service idea to other kids in the neighborhood. "It's very common for adult entrepreneurs to be those who started lemonade stands or went house-to-house trying to make money when they were children," says Leann Mischel, a management professor and entrepreneur at Susquehanna University's Sigmund Weis School of Business.
Entrepreneurial genes 創業基因
In the nurture vs. nature debate, there's new research showing that the drive to start companies may be genetic. Researchers compared self-employment among 609 pairs of identical twins and 657 pairs of fraternal twins in the United Kingdom. They found that nearly half (48 percent) of an individual's tendency to be self-employed is genetic. For example, genes leading someone to be extroverted are key to salesmanship, a vital trait among entrepreneurs, says Scott Shane, an entrepreneurship professor at Case Western Reserve University and one of the study's authors. There's also evidence people with dyslexia are more likely to become entrepreneurs. London's Cass Business School says entrepreneurs in a study of 215 managers were five times as likely as corporate managers to have dyslexia. Why? Dyslexia forces people to hunt for creative ways to steer through life. Famous entrepreneurs with dyslexia include discount stockbroker Charles Schwab and Virgin's Richard Branson.

Family support 家人支持
Prepare for crazy-long hours, including weekends, during a company's startup phase, a workload that's also taxing for an entrepreneur's family. And vacations? What are those? About two-thirds of small-business owners said they planned to take a vacation of a week or more this summer, but more than half planned to check in with their companies at least once daily, American Express found in a survey. "Starting a business can require 80-to 100-hour weeks," Mark Ciavarella, an assistant management professor at Bucknell University, said in an e-mail. "Many spouses/partners don't understand this and won't tolerate it." As startup adviser Ralph Sherman of Createabank near Detroit said, you know you're an entrepreneur when "your family has been looking for your picture on a milk carton."

Money doesn't motivate 錢不是重點
Two of the United States' most famous entrepreneurs -- Bill Gates at Microsoft and Warren Buffett at Berkshire Hathaway -- are also the two richest Americans. But they were driven to create great companies, not just huge fortunes. Indeed, Gates and Buffett are combining their riches to create a $60 billion philanthropic powerhouse in the Bill & Melinda Gates Foundation. "Entrepreneurs are much more interested in 'wealth' rather than 'riches,'" says Scott Laughlin, director of the University of Maryland's tech entrepreneurship program. Riches are piles of money, he says; wealth is broader, encompassing less-tangible rewards such as respect and independence. So, would-be entrepreneurs need to examine how they expect to be rewarded. "If the compensation is just cash," Laughlin says, "then the practice of entrepreneurship will not be very rewarding."

Passion 熱情
You don't just think you've built a better mousetrap. You feel it in your gut, and know the world will be much better if only you can get your idea to market. "When something is important to you, then you know it with your heart as well as your brain," says Bob Barbato, a management and entrepreneurship professor at Rochester Institute of Technology. "You infect others with your passion, and they believe in you."
The flip side of passion is impatience with other people's ideas, says Amy Millman, president of Springboard Enterprises, which helps startups led by women find investors. The would-be entrepreneur's attitude, Millman says, is: "I know what I want to do, and I know how to do it." Conventional wisdom 20 years ago said a black woman from rural Mississippi would have a tough time launching a career as a TV host on even the lowest-rated show. But one such woman went on to launch her own company, Harpo Productions. And now, Oprah Winfrey is one of TV's biggest stars, ruling over an estimated $1.4 billion fortune.

Pragmatism 實際
As passionate as entrepreneurs must be to drive startups forward, they also know when to cut losses. "Know when to give up on an idea," says Lou Marino, an associate professor of entrepreneurship at the University of Alabama at Tuscaloosa. "Not every idea an entrepreneur has is going to be a home run." Giving up doesn't necessarily mean the business idea was bad. Instead, it might be the right idea at the wrong time, as with thousands of dot-coms launched in the late 1990s before household high-speed Internet access became widespread, making viable all the offerings those dot-coms hoped to sell.

Risk-taking 勇於冒險
You know startup success isn't guaranteed. Still, you don't flinch at the thought of betting your severance pay or retirement savings on self-employment. Would-be entrepreneurs are calculated risk-takers, like world-class mountaineers, says Vineet Buch, a principal at venture-capital firm BlueRun Ventures in Silicon Valley's Menlo Park. "They hammer-in protection on the way to the top, but don't let the thought of falling slow their steps as the slope gets steeper and narrower," he says. "True entrepreneurs strive to control risk while still thriving on it." Martha Stewart risked leaving the safety net of publishing giant Time in 1996 to launch her Martha Stewart Living Omnimedia. She successfully took that company public, becoming one of the world's most famous entrepreneurs.

Strong ethics 道德高尚
Startups depend heavily on good first impressions when entrepreneurs hire employees, court investors and line up customers. In a hyper-competitive economy, any whiff of dishonesty can deep-six a new enterprise. Penn State University's Anthony Warren, who advises venture capitalists, says honesty and trustworthiness are high on the list of attributes he looks for when he considers recommending a venture to potential investors.
"Who wants to be in business with someone you cannot fully trust, especially in the startup phase where the stress levels are high?" says Warren, director of the school's Farrell Center for Corporate Innovation and Entrepreneurship. The founders of Google, Sergey Brin and Larry Page, famously created a "don't be evil" mantra when they took their online search giant public.

Tech ease 擅用科技
Feeling comfortable with technology is crucial, because computers, software and other gadgets are key to launching a business in the fastest-growing economy, the service sector. Startup costs there have plummeted as prices fell for powerful computers and software. Those lower prices came as the Internet let entrepreneurs tap global markets for engineering, accounting and other services. Setting up a small office with a laptop, fax machine, cell phone and other gizmos costs as little as $5,000. Add a professional-looking Web site for $500 or so, and you can compete with bigger, more established companies. But you can't take advantage of those lower costs if you aren't comfortable using popular word-processing, database, spreadsheet and presentation programs.

Tenacity 韌性
Sometimes the best business ideas fail to take hold, not because there isn't demand, but because the startup was undercapitalized, or the entrepreneur lacked management know-how or simply gave up too soon.

"If you really believe in it, you keep fighting for it," says Earl "Butch" Graves, president and CEO of Black Enterprise, the magazine founded by his father, Earl Sr. One-third of new small employers fail within two years; and 56 percent are toast after four years, says the Small Business Administration. About 672,000 small employers launched last year -- but 545,000 others closed, the SBA says. A nobody entrepreneur who started a variety store in Arkansas in 1945 eventually lost the business when his landlord wouldn't renew his lease. But he didn't give up.

"I've never been one to dwell on reverses," Sam Walton recalled in his autobiography, "and I didn't do so then."
The company he fought to start, Wal-Mart, is now the USA's biggest private employer, with more than 1.3 million workers.

1. Did you franchise your lemonade stand when you were 8 years old?
2. Do you have "entrepreneurial" genes?
3. Are your spouse, children and parents loyal?
4. Is wealth a better reason to start a business than riches?
5. Do you love your better mousetrap?
6. Do you know when to replace passion with pragmatism?
7. Ever doubled down in Vegas?
8. Are you honest, trustworthy and committed to avoiding evil?
9. Do you know a spreadsheet from a bed sheet?
10. Do you have the tenacity of a pit bull?

What's your score?


1-3: Don't quit your day job.
4-7: Begin saving startup money
8-10: Watch out, Donald Trump!

Thursday, May 11, 2006

Look Mom, No Application Servers, Look...MOM!

In the unlikely event that you're not familiar with my gas station, you can find my previous essays at Recently, I've conducted a small survey among my truck drivers. I asked them just one question: "What do you think of application servers?" The most popular answer was, "I don't need no stinkin' application server." And truck drivers usually know what they're talking about!
You may think that now I'll start selling one of the popular application frameworks. Wrong! The idea of these frameworks was nice: get back from complex containers to programming POJOs. But while trying to provide alternatives to container services, each of these frameworks ran into the short-blanket syndrome: something is always sticking out. XML is sticking out big time!
To simplify Java programming, developers are paying the high price of adding unmanageable amounts of XML descriptors, mappings, wirings, and other plumbing. Twenty years ago .ini files were widely used, 10 years ago .properties replaced them, and after the Y2K problem was solved, people were bored and started investing their time in XML.
It started quite innocently: XML is better than HTML, then DTD came about, XSLT, XPATH, XQuery, XML farms, XML processing hardware, and on, and on, and on. Basically, the proper way to name today's POJO is XPOJO. You know what I mean. Hopefully, Java annotations will slow down the X-hype. I'm already using Java 5 in my agile business, and as soon as Mustang is released, big corporations will switch to Tiger.
Let's return to the main subject. One of my readers asked if I was planning to write a piece on how to select an application server. I answered, "No, because I'm not sure if they're needed."
I believe that at least a half of today's business applications don't need one. In my gas station, I'm going to implement a set of client/server applications with rich clients talking to each other using Java messaging, and most likely, I'll need to implement an Enterprise Service Bus (ESB) to communicate with a couple of old applications that I inherited from the former owner of my gas station.
My newly developed applications will use rich application clients living in a Web browser, but they'll run in their own virtual machines (no AJAX by the pumps!). I've already started working on a more serious manuscript on RIA (see To make a long story short, I'm planning to use/implement SOA, RIA, MXML , JWS, JMS, MOM, JNDI, ESB, JTA, DAO, JDBC, DBMS, and a Web Server. Raise your hand if you know how to spell out each of the acronyms used in this article so far.
I know, I know. Ten years ago, people who could spell out VB and SQL were able to find a nice paying job in a heartbeat. Forget about it. I can recommend a handy Web site called In some cases it gives you too many versions for your acronym, but key in JTA and you'll find that it stands for Java Transaction API (it's right above Japan Toilet Association). Since I'm not going to use the J2EE application server, I have to find transaction support somewhere else.
Consider the use case of a typical business application without an application server. The front-end reacts to various events by putting messages (Java value objects or key-value pairs) into a remote message queue (orders, requests, etc.). A server-side JMS listener picks them up from the queue and starts business processing the messages received. This is where transaction support comes in handy. For example, from a business perspective saving a customer's order in a database and making a JMS call for further processing can be considered one unit of work, which has to be rolled back if any of these actions fails. That's why a JMS listener has to be able to begin, commit, and roll back transactions.
Communicating with the database can be done using a simple DAO/JDBC combo. Create a tiny .properties file with a dozen parameters (the data source to use, maybe some external URLs, and a couple of others). That's it. This is what I call real POJO programming. Did I miss anything? Oh yeah, JMS is just an API, so we need a transport/storage for our messages, and this is what Message-Oriented Middleware (MOM) is for.
While there are several Open Source JMS/MOM implementations on the market, I'm planning to use ActiveMQ from Logic Blaze. The product has been on the market for years, has good reputation, supports JTA/XA, and has a large user community. Look at the ActiveMQ list of features, and you'll see that it offers more than any small business needs. Another pro is that the same vendor offers an Open Source JBI-based ESB implementation called ServiceMix. But this is a topic for future discussions. And the best part is that this middleware is available for free.
Not everyone may like this architecture, but let me remind you, we're talking about a small business here. One of my readers sent me an e-mail asking, "What if this application is supposed to be used by thousands users?" I wish... This is just a gas station! When you're architecting your next application, try not to get into a Google/Amazon state of mind unless you work for them. If you're not dealing with thousands of users, just use a simple Data Access Object, write a couple of SQL statements here and there, and make a dozen JDBC and JMS calls. And MOM will be a good, reliable foundation for creating loosely coupled applications with robust transactions, persistence, and failover support.
© 2006 SYS-CON Media Inc.

Wednesday, April 26, 2006

Openstructure: A Call for Open Source Reform

This is the third paper in the series, The Open Source Monopoly. The goal of the series is to expose a trend in open source that is leading to the creation of a new breed of 'effective' monopolies by commercial open source companies. In this paper, a solution is presented for how the open source community can reverse this trend and insure the long-term survival of the movement.

This paper has led to the establishment of the Openstructure Community.

The marginalization of open source

In the last paper, The Economics of Open Source, I noted that there seems to be an increasing split between the "professional" open source companies and the "pony-tailed faction" of original open source developers and users. One of the many things that the movement has struggled with is to define how money is to be made from open source. An obvious way is for companies to offer paid support services for open source products - there are plenty of examples of this. But the dual-licensing model popularized by Trolltech, MySQL and Sleepycat is becoming increasingly prevelant. While I think this is a bad sign for open source, it is also the natural progression of the technology industry in which a new category of brand names have sprung up to create an effective monopoly of the movement.

While open source developers continue to code away, their movement is being reconfigured and dominated by the commercial open source companies. The latter seem to have forgotten that it is the thousands of individual developers and adopters who are responsible for the marketing term "open source". Instead, the focus of these companies is on the growing number of large IT organizations looking to open source as a cure for the traditional ills of IT. They hope to sway these organizations by branding themselves as the new face of open source.

How to avoid brand-name thinking

I've spent some time in the previous papers outlining the role that brand creation has to do with open source. Now I wish to address exactly why this is not a good thing for open source.

Brand name thinking boils down to the belief that a well-established name automatically guarantees a certain amount of quality and longevity for the product. It establishes a trust in the user for the product. We see this every day in the consumer market. Companies spend billions to get their name in front of consumers and for one simple fact: as consumers, we really don't have the ability to decide whether or not a product will work for us. While it may seem very sophisticated to do comparison or feature shopping, most people still make brand-name decisions. Even if they go through the exercise of comparing features and prices, they still ultimately choose based on what makes them feel "right". That is the point of a brand name. It establishes a feeling of trust which, when all else fails, is going to drive decision-making.

Now there are of course people who think beyond the brand names and buy less known products because they really are thinking about how to meet specific needs. This is why products that aren't brands can stay in the market, albeit a more limited one. However, in the majority of cases, you will find the same consistent brands in people's shopping baskets, driveways or tool sheds. Is this a bad thing? For the brand name companies no. For quality products that never make a name for themselves and end up forced out of the game, yes (the Packard automobile is an example). For consumers who end up with high costs and poor quality from the brand name, yes.

It is the same in the IT world. Quite frankly, a great deal of this could be avoided if IT managers admitted one dirty little secret: it is very hard to understand technology! That is why the industry is so rife with buzzwords. Most decision makers have a hard time articulating business needs and an even harder time evaluating IT products that will fulfill those needs. It actually takes a great deal of smarts to do this. We all think we are doing it, but it is much, much harder than it looks. As a result, our thinking inevitably drifts into a series of feature or quality buzzwords that we cling to like a drowning man clings to a stray plank. We seize on words like "TPM", "throughput", "query optimization", (to use terms from the database world) and then use these to evaluate the features lists of competing products. I'll bet there are many IT managers out there who don't really know whether these features are pertinent to their needs or not. They believe that they must have them and that one they get the product with the most features, the business needs will be magically solved.

The most important point I can make here is this: if you cannot articulate your business needs and identify IT products that can help you fulfill those needs, you end up thinking in terms of concepts. When you think in terms of concepts, whether feature buzzwords or more general buzzwords like "mission critical" or "enterprise interoperability", your thinking is divorced from your needs. And when that happens, the marketing departments have got you. No matter how objective you think you are, you will inevitably find yourself choosing a brand name.

Being objective is supposedly the goal in critical thinking. But as I pointed out in "The Open Source Monopoly", you actually should be subjective, which is much more difficult. If your thinking is not rooted in the subjective needs of your business, you loose any ability to judge whether one product is better than another for your business. You then become concerned with external "facts" or concepts like the buzzwords I just mentioned. Objectivity is a game played very well by marketing folks: any brand name can always "prove" that their product is better based on objective criteria.

You might think that I'm being overly harsh to IT managers in accusing them of brand-name thinking. I do realize that many IT managers are concerned with valid questions such as: "will this product be around for the long term?", "can I get adequate support on this product?", "will this product interoperate with other products I have so as not to incur additional integration expenses?". With questions like this, it is hard not to think in terms of brand names. The brand names promise all these things: longevity, support, interoperability. This is, for example, why a Wall Street company is more likely to choose Red Hat over White Box Linux, or MySQL over PostgreSQL.

The fact of the matter is that the marketplace drives the industry. If IT managers demand the right things, the industry has no choice but to provide them. I believe that after the decades of waste in IT it is time for a new level of accountability. Since there are so many permutations possible in technology, there are many more pitfalls. Therefore, IT departments should be held to a higher standard than other aspects of a business.

The mission of an IT organization should be very clear: "to use technology as a tool for enabling business functions". That is the standard of accountability. To fulfill this standard, all IT personnel should be trained to understand the company's business needs and to know how to derive technology requirements from them. This seemingly basic training will save companies from many a bad choice.

Being grounded in the facts of your business means that you can't be swayed by false promises nor deceived by buzzwords. As an IT manager, you can go out to the industry and choose only products that will fulfill your business requirements. You can cut through the marketing hype and see if there is really something there. You can, for example, find that a Red Hat solution may not serve your needs as well as a Debian platform with a solid support company to back you up. You may find that the Java middleware architecture model being marketed by JBoss adds layers of complexity to your business without any true value. Conversely, you may find that moving your data warehouse to MySQL will save you huge sums of money, even though you may still pay for licenses.

The Product Infrastructure

A good product, whether open source or not, does me as a business owner absolutely no good if I don't know exactly what it does, how to use it, how to use it well and how to use it securely. In my opinion, the greatest criticism of open source is that projects become all about their products and very little about what I call the "Product Infrastructure". The Product Infrastructure is the information and support around a product that is designed to maximize its usability.

Each day dozens of open source projects announce new releases or creations. This emphasis on more and more products, and newer and better releases, is a serious hindrance to usability. Personally, I would rather see a product line completely frozen in the interests of good documentation and support procedures. I think that it is time we step back from the frenetic pace of development and look at what IT departments really need. What they need are not more products, but the infrastructure around them that helps us use them.

When Wall Street companies look at open source products, the reason why they are more likely to choose the brand names that I have talked so much about is that these brand names are willing to provide the product infrastructure. JBoss, for example, provides Tomcat support and hires Tomcat developers in order to gain legitimacy. I don't think that the brand names should be the only ones providing these services. There is no reason why the same open source community that developed the products could not also provide product infrastructure services commercially. It requires a new evolution in community development but one which I think we are all capable of.

Openstructure: an infrastructure for open source products

Accordingly, I'd like to define a new term "Openstructure". This term encompasses all the support services required to make open source products usable for the long run. It is an approach to looking at the product as a whole, not just from the development side. Specifically, it includes:

a.. premier documentation
b.. training services
c.. tiered support services
d.. integration services
e.. security alerts
f.. intuitive administration and operator interfaces
g.. interoperability testing
h.. load testing
i.. release criteria
j.. configuration standards
These services should not be limited to commercial companies providing 24x7 support: everyone in the open source chain needs to participate. Projects, for example, can concentrate on documentation and solid release criteria. Support companies can provide the support services and feed information back into the projects. Integration consultants can build interoperability matrices or "best practices" guides that can help inform decision makers of what products work well together. By taking care of the entire process, we as a community can insure the viability of our products for the long haul. And we can prevent large companies who are open source in name only from coopting the movement while we are too busy looking at our vi or emacs sessions.

There are already plenty of companies making money by providing support for open source products. That is quite legitimate, so long as these companies actually have skills in these areas. It takes a lot more than reading the documentation on the Apache Tomcat site in order to provide Tomcat support services. You don't have to be a project contributor, but you'd better know that source code as well as have the experience of installation and managing production Tomcat installations.

What I'm after, however, is something more. Two years ago, a colleague and I began working on the outlines for an organization I call the Digital Masons Guild (no relation to Freemasons). The mission of this organization is to provide exactly the kind of openstructure services I am talking about. The manifesto of the Digital Masons Guild reads as follows:


Digital Masons is a guild of software artisans who have pooled their skills in order to provide world-wide and world-class software development services. As members of the Digital Masons Guild, we hold to the following principles:

1. Our guild is based on the belief that, thanks to the Internet, an organization of worldwide software professionals can act as a single team.

2. We choose only members who possess outstanding technical skills, a holistic grasp of the software development lifecycle, a deep understanding of business requirements, a commitment to quality and, above all, the highest professional integrity.

3. A fundamental principle of our mutual association is that we share our experiences, design skills and software components for each and every project we work on.

4. While our market is global, our structure enables us to deliver localized services to our clients.

5. We believe that the combined intellectual and technological resources of our organization, along with a flexible and nominal cost operating structure, offers our clients significant benefits over traditional consulting options.

6. We believe that not only has open source software reached the same maturity as proprietary software, but it offers organizations significant cost benefits in today's economic climate.

7. We believe in a paradigm of software applications composed of modular components and based on open source platforms but customized to client requirements and backed up with long-term support options.

8. Our goal is to bring true long-term value in technology to our clients. We are committed to avoiding technology choices that are merely trends or will lead to a "lock-in" to a real or effective monopoly.


This manifesto can also be found at within a few days, you'll find additional documentation there as well. If you are interested in participating or have constructive suggestions please contact me.

This effort is only a beginning - I'd like to see much more. In particular, I think it would be a great idea for leading open source organizations like the Apache Software Foundation or FreeBSD Foundation to sponsor such groups. I do not think this is contrary to their mission; instead, it complements it. I believe that if large IT organizations find out that they can receive infrastructure services from ASF for Apache, Tomcat and Geronimo, for example, they would be far more likely to convert from proprietary solutions to ASF products. And if they see that ASF is dedicated to enterprise-level stability and interoperability in their products, and works closely with openstructure organizations from various Linux projects to insure that, they would be sold.

A new entrepreneurship

More than anything else, the open source movement represented a new class of entrepreneurs: people who found a way to express their creativity and genius in technology. These people saw the dangers that proprietary monopolies posed to the freedom of the individual to innovate. They did not want to end up as operators of giant Microsoft or IBM shops. They wanted to figure out better ways to do things and be able to make a serious difference in their work. And they did.

Since the beginning, however, the open source movement has been conflicted about money. Some have pushed for a radical interpretation of the "free" nature of open source, trying to devise a means for insuring that the freedom to innovate and create would never again be threatened. Many people mistake this interpretation as tantamount to a contempt for making money. That is missing the point completely. I believe people like Richard Stallman are more concerned with the future of the movement than anything else. Unlike many in the movement, they do not believe in the "they would never do that" argument. Instead, they are concerned that the freedom and entreprenurship of the open source movement will some day be gone and that with it will go their livelihoods. This is a valid concern. And as I have shown, this is all the more valid given that we are watching a new breed of monopolies in the making, one that will someday threaten the job of the software developer.

What I am proposing is that we can, as a community, figure out a way to keep our freedoms alive. We do not have to watch commercial open source companies turn open source into a marketing term designed to get them taken seriously by the IT departments of Wall Street firms. We can build up a infrastructure that cannot be coopted by venture capitalists. We can grow our own names, not by slick marketing, but by a reputation for sheer brilliance, responsiveness and innovation. We can get our names in front of those companies who are considering the move to open source. And we can insure that open source-based enterprises work: not just now, but for the long haul. We can do this because, as a community, we won't be going away and we can guarantee that the products we build, we will also support.

A call to open source project groups

Accordingly, I'd like to issue a call to open source project groups to consider the benefits of developing a support community. We've seen how well people can work together to produce quality software. Now these same people can work together to support that software and enable organizations all over the world to move to an open source platform and avoid being locked-in to a new breed of big name companies.

I also urge project groups to carefully consider the need for new projects or versions. The more projects there are, the less any one will stand out. The more versions that are produced, the more room there is for integration failure or the opening up new security or performance holes. I would also call on projects to develop release criteria, such as those implemented in many IT departments. These criteria should be documented publicly along with release test results and should include such things as integration testing, regression testing and load testing.

More than anything else, open source projects should spend time in making sure their products are as easy to use as possible. Microsoft has succeeded in part because they have been able to create user interfaces that are easier to use than their Unix-based counterparts. There is no reason why the combined geniuses of open source developers cannot do better! I would love to see a new open source project that worked on the specifications for application user interfaces. These specifications could cover GUI applications as well as server applications. I think it is also time to come up with an open standard for server management, something that does a much better job than options like JMX.

A call to IT managers

Sanity in IT departments can only be achieved through a fundamental rethinking of the purpose of IT and technology. The foundations of this thinking are your business needs and how technology can be used to fulfill them. While I offer specific consulting on these subjects, much can be achieved simply by taking an honest look at out-of-control IT expenses and projects! There are many ways to make IT more efficient if you are willing to be honest about your problems.

The promise of open source is real and is being seen in companies all over the globe. Open source is a solid move with immediate cost benefits. But beware of vendor lock-in. Look past the big names and find out what other options exist. If you find a non-profit organization with a really good product, consider supporting its efforts to provide product infrastructure services. This will help keep the open source community vibrant and healthy.

A call to commercial open source companies

From my earlier critique of commercial open source companies, you might think that I don't like any of their products. Actually, I do. I like Berkeley DB quite a bit, and although I like PostgreSQL better, I have happily used MySQL for many years. I'm also pretty experienced in RedHat Linux and Fedora. I believe they all have value. For this reason, I believe that commercial open source companies should focus on the products and not in spinning them a certain way. Really, if a product is open source only because the source code is available, DON'T CALL IT THAT! Instead, rely on the strengths of the product itself.

One thing that I do like about commercial open source is that the prices are relatively low. If I was in the market for an embedded database, for example, I wouldn't hesitate to pay Sleepycat licensing fees. I have no problem with paying for something of value, nor should anyone else. It is when a serious and true movement like open source is turned into just another marketing term that I have a problem.

Honesty in business may not seem to get you very far, certainly not as far as doing whatever you have to do to get a profit. But I think that could change. If the IT side of business starts waking up to the realities of technology, I believe they could demand a greater accountability and openness from the industry. And there is no better way to be "open", than to avoid the kind of marketing double-talk that you find on the websites of most of the companies I have discussed. Be open by being honest!


Openstructure: A Call for Open Source Reform is Part 3 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies, while Part 2 explored the economic models of these companies in more detail.

This article was first published on 1/21/05.

The Economics of Commercial Open Source

This is the second paper in the series, The Open Source Monopoly. The goal of the series is to expose a trend in open source that is leading to the creation of a new breed of 'effective' monopolies by commercial open source companies.


This article expands upon my previous paper, "The Open Source Monopoly". In it, I laid out the premise that commercial open source (COS) companies of the likes of Red Hat, MySQL and JBoss are examples of a new trend in the open source movement. In this trend, which I call the "Commercial Model" of open source, these companies have positioned themselves to be the de facto "names" in the open source movement. While this may be seen as a natural evolution of the marketplace, I believe that it violates the true spirit of open source, a spirit based in freedom, artistic expression and technological innovations. The result of this trend is what I am calling an effective monopoly, one in which a select group of brand name open source companies dominate the industry. Thanks to this monopoly, open source is ending up less the revolution it was intended to be and more an opportunity for the industry at large to redefine old practices under new terms.

In this paper, I wish to explore the different economic models used by commercial open source companies. Specifically, we can distinguish various strategies that these companies use, what I call the "Dual License Strategy", the "Cell Phone Strategy" and the "Ecosystem Strategy".

The Dual Licensing Strategy

Dual licensing is the technique whereby a COS company develops software that is called "open source" because the company makes its source code freely available. However, since the company owns the copyright to the software source code, it is able to distribute the software under two different licenses: one open source, one commercial. The open source license, typically the GNU General Public License or GPL, allows you to take the software code, modify it, redistribute it or incorporate it into another project - all usually subject to various restrictions. For example, under the GPL you cannot redistribute the GPL'd software in unmodified or modified form, nor any other project that uses all or part of the GPL'd software, unless you too use the GPL license. This means that you cannot take the GPL'd code, create your own brand of software with it, and then sell it for profit. Of course, if you want to do that, the company conveniently offers you its commercial license.

Dual licensing is used in various forms by such companies as Trolltech, Sleepycat, MySQL and Red Hat. It is precisely this trend that I see to be so dangerous to the spirit of open source. In my opinion, this dual licensing model amounts to a hijacking of the open source movement in which the "open source" nature of the company is used as bait to an increasingly receptive marketplace.

Naturally, this opinion is not without opposition. One of the favorite arguments of its opponents is that the code is truly free and within the spirit of open source because you can always fork your own version under a license such as the GPL. Many open source proponents therefore welcome and even encourage dual licensing because they see in that the continued development of their movement.

In order to understand how this is incorrect, we have to look at this from the perspective of these COS companies. Suppose you are starting such a company. Your mission is to make money from open source software. What you need is an economic model in which you can take something free and convince people to pay for it. In a brand name-driven culture, there is only one solution: you need to create and successfully market a brand name.

Creating a brand name in the open source world is not necessarily a matter of producing a quality product (though it might be). It requires a balance between gaining the support of the open source development community and getting your message in front of corporate IT decision makers. To the open source community you need to present yourself as a benevolent guardian of the true spirit of open source. After all, you need their support and even more importantly, their work. To potential clients, you need to present an image of trust by selling a concept, a name.

The dual licensing model allows you to achieve both ends (at least so far). With the open source license you guarantee yourself a user base among the community of developers. You may even set up a specific development community around your product so that developers can actively participate in the evolution of your product. On the other hand, the commercial license gives you a way to make money, increase your marketing budget and move into a position of dominance in the marketplace.

Let's look at an example. Red Hat Inc. distributes two versions of Linux: a commercial version, Red Hat Enterprise Linux (RHEL), and an open source version, Fedora. Originally a free download (and called simply "Red Hat"), the RHEL line was created in 2002 and currently costs anywhere from $349 to $2,499 per server. RHEL is positioned to attract companies who want to move to Linux and want the promise of enterprise-level performance and support. On the other hand, the open source licensed Fedora version is free for anyone to download but is not supported and changes more often. The hope was that the Fedora project could attract a development community which would enable innovations to feed into the RHEL version.

Not every one was happy with Red Hat's dual licensing scheme when it came out. Organizations that had invested in a Red Hat platform found that they now faced unexpected licensing fees. Since RHEL sources could be obtained for free, however, new Linux variants started showing up that were built from those sources. One of the best known is White Box Linux which was created by a Louisiana public library that didn't want to move to RHEL and start paying licensing fees. Instead, they took the RHEL source RPMs (SRPMs) and created their own distribution. (Apparently, they can continue to maintain compatibility with RHEL until 2008 when RedHat will stop releasing errata SRPMs for RHEL.)

You might think that I've just proved the point of those who say that the ability to fork RHEL keeps it open in the spirit of open source. Look at it from RedHat's perspective, though. They get community involvement and support for their commercial product. In fact, they recently announced a series of changes to their process aimed as increasing developer participation in Fedora and enabling community changes to Fedora to feed more easily into the RHEL. Free work to make their commercial product better. In exchange, all they have to do is post their source RPMs as free downloads.

Here's the key though. The fact that anyone can fork a distribution off RHEL does not have any serious affect on their market share. Don't think that Wall Street companies are going to be looking at alternatives to RHEL. They would never consider the likes of White Box Linux, Tao Linux, CentOS and others, let alone even find them. They want a brand name they can trust. And RedHat has successfully positioned themselves to be that brand name. Unless we see a radical shift in the industry, the market penetration of all RHEL derivatives will never amount to more than a tiny fraction of total Linux installations.

Giving source code away is not a huge risk for companies following the dual licensing strategy. In exchange for becoming a brand name in the open source world, they allow a certain percentage of people to use their software for free. However, they are not concerned with that percentage of people - their sights are on the growing open source conversions being contemplated in IT organizations around the world. That is their market. It is not the odd developer or odd company that is willing to work with the source code.

Whereas Red Hat Inc. offers one product under the commercial license and another under an open source license, other companies offer two different licenses for the same product. Such is the case with MySQL AB which has been in the dual licensing business for a while. It's flagship database product can be downloaded for free under the terms of the GPL or can be used commercially under the commercial license.

Which license you choose basically comes down to the interpretation of the GPL. For example, if you want to distribute MySQL (or its drivers) with a non-GPL application, you need a commercial license. This applies not only if you actually distribute MySQL, but if "as part of utilizing your application, the end-user must download a copy of MySQL". It is also recommended by MySQL that you need a commercial license if you "distribute MySQL Software within your organization". Finally, there is a special clause that allows you to distribute MySQL client libraries with Free/Libre and Open Source Software (FLOSS) applications under the terms of the "FLOSS License Exception".

The interesting thing about MySQL and the GPL is that there is a certain amount of interpretation at work. What exactly does it mean to "distribute MySQL Software within your organization"? There is no text in the GPL itself that covers the situation. In fact, the Free Software Foundation (FSF) FAQ on the GPL notes that you are actually free to release GPL'd software internally within your organization.

There are plenty of those who say that GPL is GPL and so as long as you stay with its terms MySQL has no legal claims on your use of it. However, it is quite valid to ask whether MySQL AB could be attempting to restrict the GPL beyond the generally accepted terms of the license. There are some gray areas in GPL itself, particularly when it comes to communication between software components via standard protocols. But even if MySQL AB itself respects the generally accepted interpretation of the GPL, it is not beyond the realm of possibility that another dual-licensing company will not. The key question is whether organizations that use software from a dual-licensing company under the terms of GPL will someday find themselves in a difficult situation. There is no code of honor when a profit must be made.

JBoss and the "Cell Phone Strategy"

When it comes to a company like JBoss, it might appear that the dual licensing strategy is impossible, since individual contributors and not JBoss owns the copyright to the source code. Currently, the revenue model for JBoss is built around support of their products. However, it has already been pointed out that this model is not viable in the long run (especially for capitalizing on the $10M venture capital investment it received last year). The fact is that JBoss is going after the market share enjoyed by BEA, just like Red Hat is targeting Sun's market. You can't beat BEA by support contracts alone: you need a better revenue model. And JBoss execs don't rule it out. Marc Fleury, for example, admits about dual licensing that "on new layers it may make sense".

Although a very small company, JBoss has been extremely successfully in establishing their name in the J2EE and middleware world. With the JBoss Enterprise Middleware System (JEMS), the company now has its sights set on becoming the de facto choice for non-proprietary middleware. They have also become heavily involved in the new EJB 3.0 specification and the future of J2EE in general. The question again comes down to strategy. It is a possibility, in my opinion, that some generation (or "layer") of JEMS will eventually become a commercial product. JBoss is certainly keeping that option open. I also have misgivings when they are actively recruiting leading open source developers like Remy Maucherat of Apache Tomcat fame. Does this foretell a day when formerly open source developers will be creating code under the JBoss copyright?

Regardless of the possibility of dual licensing, I believe JBoss' true strategy is what I call the "Cell Phone Model". A while ago, cellular phone companies realized that if they gave away cell phones in exchange for contract agreements, they would have greater success among consumers then if they sold them. And the market has proved them right. Most Americans now own cell phones or, more correctly, they own a contract on one. By giving away a disposable product that has in itself little long-term value, the cellular companies have guaranteed themselves an ongoing revenue stream that far exceeds anything they could get from actual sales. I believe this is also true of JBoss.

While open source products are hardly disposable, they cost little to make if open source volunteers are doing all the work. In the case of JBoss, they have a seemingly vibrant development community working for free under their management. While not all members of that community will agree with this portrayal, consider the facts. JBoss takes a free product, wraps it up in very good marketing (remember, they have venture capital to spend) and uses it to go after domination of the middleware industry. What part of this do the open source developers see? The satisfaction of knowing they are helping create a popular product? The individual freedom to download and use JBoss on their own? Certainly they latter is of great benefit to some, but not quite on the same level as the benefits that JBoss hope to enjoy.

The difference between JBoss Inc. and the likes of Verizon is that the latter makes you sign a contract for your "free" phone. JBoss does no such thing. But as I have been showing in these papers, it is the effect of these business practices that we have to consider. The reason why companies are turning to JBoss and their middleware products is precisely because of the support options. While there is no such thing as required support, any kind of large-scale IT organization using JBoss products is almost always going to buy support (like the French "Direction Generale des Impots", for example). While the majority of JBoss downloads are by individuals or small organizations that won't utilize support, they are not the real market.

"They would never do that"

If there is one argument I find to be particularly naive, it is that "they would never do that". In various discussions about JBoss, I've heard that a few times. The naivete comes from a lack of understanding how economics works. I've been involved in startup companies and met with venture capitalists. Venture capitalists are not interested in the ideals of open source but only a specific rate of return on their investment. If they don't get that, they either lose interest or use their voting power to change corporate direction. This isn't any grand and dire prediction, it is an everyday fact.

To those who believe that GPL and the spirit of open source protects the movement from any sort of hijacking, let me point out that it is only the motives of those that control the money that really matter. Today, it is the investors that matter most. Tomorrow, it will also be the companies that buy out the open source companies of today. Idealism is no match for a lucrative buyout deal - just look at PeopleSoft and Oracle. As I asked before, what happens when a company like HP, IBM or even BEA buys JBoss?

The Ecosystem Strategy

The "Ecosystem Strategy" is one in which a COS company creates a network of partners or preferred independent software vendors (ISVs). The goal of this network or "ecosystem" (the new hot buzzword) is to create a lock-in of sorts. This is hardly new - companies like HP, Sun and IBM have been doing it for years as a way of creating an effective monopoly. Nor is it incompatible with the other strategies already mentioned - in a way, it complements them.

Let's look at Red Hat Inc. again. Oracle is one of their major partners. What this means is that the two companies work closely to insure that their software plays well together. If you are a big company wanting to run Oracle on Linux, you'll therefore be more likely to choose Red Hat with its Oracle integration. You won't be likely to choose White Box Linux, Debian, Mandrake, FreeBSD or any other such variant from a non-profit organization.

The strategy here is to take an open source product and use it as the core of a real or contrived infrastructure. An operating system is probably the easiest thing to use as the center of an infrastructure. In speaking of Solaris 10, for example, Sun president Jonathan Schwartz rhapsodizes:

Together, Sun and SAP are going to drive business solutions across the entirety of our SPARC and x86/Opteron platform customers. This is really the final brick in the wall for us with partners - Oracle, Veritas, BEA, CA, EMC, Sybase, Siebel and now SAP. That's a fantastic list (and there are hundreds of others who've also signed on). It takes an ecosystem to raise an OS, and volume to attract partners.
Then we read from Red Hat Inc. that:

Red Hat brings together industry leaders to build an ecosystem around Linux and open source technology.
By empowering a complex network of hundreds of leading hardware, software and service provider vendors, Red Hat is returning the power of choice and openness to partners and their customers to build a certified, open source solution.
And from JBoss:

The JBoss Partner Program was created to build a network of service delivery, software, and technology partners that could enhance the proliferation and quality of deployments based on JBoss Inc. products. Today, the JBoss Partner network has grown to over 60 authorized partners including IT industry heavyweights such as CA, HP, Novell, and Unisys.
Let me be very clear here. There is nothing wrong with partnering with software companies providing true value in technology. True value to me means enabling business functions in the most efficient and cost-effective way possible. It does not mean a layered network of complex software in which one depends on another until you find yourself wondering what the point was in the first place. When I read the above quotes, I know I'm being sold a concept, not a tool that enables me to fulfill specific business needs. I use open source software in order to run my business more efficiently. I do not need "solutions" or "ecosystems" in order to achieve this.

What good is open source software anyway?

As shown in "The Open Source Monopoly", the only requirement for being officially called "open source" is that your source code is in some way freely available for download, use, modification and redistribution. Not all open source licenses grant the same freedoms, but the general idea is the same. It is myopic to think, however, that just because a COS company allows you to download its source code for free means that the true promise of open source is being lived out.

It all comes back to strategy. For COS companies, open source is part of a strategy, not a life philosophy. Look at it again from their perspective. They have gained a leadership place in a new industry. In return, they make their source code available. Does that bother them? It is just a marketing move. Sure, people will download the source code, compile it and use. Some will redistribute it for free. But compared to the tremendous success that companies like Red Hat Inc. have had in penetrating corporate IT departments, putting code on the Internet is a small price indeed.

It is precisely because of the true spirit of open source that companies like RedHat, MySQL and JBoss now enjoy a rapidly growing reputation among IT departments. Why are companies and organizations all over the world even aware of open source? Because of the efforts of thousands of developers who believed that with a bit of ingenuity they could turn out better quality software than the proprietary options available. And software that costs basically nothing and could therefore save corporations hundreds of thousands of dollars. Some of these people were developers and others users. Together, they built projects and introduced companies all over the world to the benefits of those projects. Apache is the number one web server on the Internet, and it owes all of its success to the many rogue developers that took the initiative to build a viable open source proof-of-concept for their management. As more and more IT management saw how well open source software like the Apache web server performed, the more they considered where else the movement might benefit them. That is the power of an idea.

I don't deny the likes of Red Hat Inc., MySQL AB, Trolltech or Sleepycat the right to make money. Nor do I deny their right to produce a product and compete in an open market to be the best at what they do. I am a capitalist, after all. And I even like some of their products, like Berkeley DB. But I also believe in honesty and truth. I do not think they have the right to call themselves "open source" just because their source code is freely available. I realize that this is the technical definition, but I don't think the technical definition is what the pioneers of the open source movement understand it to be. These people did what they did precisely because they believed that they could circumvent the monopolies and lock-in of the proprietary options that increasingly frustrated them.

Put another way, commercial open source companies have forgotten the origins of the open source movement. To them, open source means little more than using a marketing term in exchange for publishing their source code on the web. In fact, Michael Olson of Sleepycat practically admitted as much. When I hear them talk about open source, I hear buzzwords designed to appeal to Fortune 500 decision makers. I get the feeling that they see hard-core open source developers as a bunch of strange and socially inept geeks whose intentions they vaguely suspect but whose impact they feel will be negligible. Take a look at a quote from JBoss' Marc Fleury:

We think we're inventing the new open source. It's not the pony-tailed faction on the communist fringe. There needs to be professionalism and credibility. There needs to be sales and marketing, and all the things that make a business.
I think this speaks of a growing split in open source, one in which commercial open source companies are the professionals, and the open source developers that created the movement in the first place are communists. Like political communists, the latter are supposed to get old and end up in a retirement home for dying Marxists. In other words, the open source idealists are being marginalized and relegated to a place so they stay out of the way of the suited professionals hurrying to their meetings with Wall Street companies.

I don't think so. In the next article in this series, I will address this marginalization of open source in more detail. While I see this as a trend, it need not be inevitable. I will show how, with the proper approach, the open source movement can stay alive and well and faithful to its origins.

The economics of commercial open source is Part 2 of The Open Source Monopoly written by Lajos Moczar. Part 1 introduced the idea that the current state of open source is headed for an effective monopoly run by a few select companies. Part 3, Openstructure: A Call for Open Source Reform presents a challenge for changing this trend.

This article was first published on 1/19/05.

References (in order of appearance)
1.. Trolltech Home Page.
2.. Sleepycat Software Home Page.
3.. MySQL AB Home Page.
4.. Red Hat Inc. Home Page.
5.. White Box Linux Project Home Page.
6.. CentOS Home Page.
7.. The open source MySQL license can be found at The commercial MySQL license is at The FLOSS License Exception text is at
8.. GNU General Public License. The GPL FAQ is at
9.. JBoss Inc. Home Page.
10.. The reference to the JBoss venture capital investment comes from "JBoss Goes Corporate For Credibility" by David Rubinstein:
11.. The Jonathan Schwartz quote comes from his weblog for 11/16/04.
12.. The Red Hat quote comes from and
13.. The JBoss quote comes from
14.. The quote from Marc Fleury comes from

The Open Source Monopoly

"The Open Source Monopoly" was originally published as a single paper. It has since become the first in a series of three. The second paper, The Economics of Commercial Open Source, looks in more detail at the economic models of companies like Red Hat Inc., JBoss and MySQL AB. The third paper, Openstructure: A Call for Open Source Reform presents some solutions to the current trend in open source and offers a challenge to the open source community for reform.

Last month I wrote an article on Apache Geronimo for JavaWorld called "A First Look at Apache Geronimo." In the summary, I stated that "Geronimo aims to be the first J2EE-certified open source J2EE server." As can be imagined, that statement generated a flurry of emails and responses, most of which claimed that in fact, JBoss was the first open source J2EE certified server.

In my reply to some of the reader feedback I received, I clarified that I did not consider JBoss open source in the same way Apache Geronimo is open source. That statement led to more controversy and so I decided to respond fully in a separate article. This paper is my response.

While it may seem a minor issue, the JBoss-Geronimo issue is symptomatic not only of problems with open source, and its definition, but with how we handle computer technology in general. As I will show in this paper, JBoss is by no means in the spirit of open source and should not be considered an open source product. But more, the fact that a company like JBoss can consider itself an open source company is a disturbing sign that the true meaning and intention of the open source movement has fallen victim to the very issues that engendered its inception.

The official definition of "open source"

Let's first consider the meaning of the term "open source". This term was actually once a service mark of the Open Source Initiative (OSI), a non-profit organization. While they now use the service mark of "OSI Certified", they continue to provide an official "Open Source Definition". Under the terms of this definition, software can be called "open source" if it and its source code can be freely modified and redistributed. The redistribution rights do not preclude a company selling such software for profit.

The OSI certifies various software licenses as open source or "OSI Certified" licenses. If you, as a company, want to call your software "OSI Certified Open Source Software", you need to submit your license to the OSI for approval. If approved, your license gets added to the list and you have a new marketing term to use for your products. Currently, Sun Microsystems is going through this process for their "Common Development and Distribution License" (CDDL) for Solaris 10. The list contains dozens of other licenses already.

Under the terms of the OSI definition, JBoss as well as other software along that model are indeed technically considered "open source" just like products from the Apache Software Foundation (ASF) or GNU are. But the real question to ask, is whether we should consider them open source and whether the OSI is in fact doing us a service with their definition. To answer this question, let's look at open source models.

The clash of the models

From its beginnings as a backwater movement among hard-core Unix users, open source has been embraced by an ever-growing community of developers and users. Today, open source projects abound - just look at the staggering numbers of projects listed on or But some clear lines have been drawn as well, so much so, that we can distinguish two main types of development models: the Volunteer Model and the Commercial Model.

In the Volunteer Model, open source software is developed by volunteers donating their time and expertise to collaborate on a specific project (sometimes, however, these volunteers are actually employees paid to work on these projects by their companies). While there are often different roles assigned to various project members, decisions are usually made based on consensus and a desire of all concerned to develop quality software. It is this model which is, of course, what started the open source movement in the first place. And it is this model which underlies most open source projects today.

Non-profit organizations like the Free Software Foundation (FSF), Apache Software Foundation (ASF) and FreeBSD Foundation are based on the Volunteer Model. What they add to the model is the umbrella of a brand-name. Projects developed under these umbrellas are usually very active, have a large user community and enjoy a certain reputation for reliability and quality. These organizations differ primarily in their area of focus and/or license terms.

The Commercial Model was born after open source became a movement; in fact, it seeks to capitalize on the publicity and popularity of the movement. In this model, for-profit organizations often release formerly proprietary code as open source. There are many examples of this. One of the first was Netscape Communications, which released its browser source code in 1998 to form the basis of the Mozilla project (the Mozilla Foundation was created in 2003 as a non-profit organization with startup money from Netscape). One of the most recent is Sun Microsystems, which just announced that Solaris 10 will be released under an open source license.

Under the Commercial Model, for-profit organizations also start brand-new open source projects of their own. Such is the case with JBoss. The model basically works like this: the company creates or sponsors an open source product and its development community. This means that, in addition to a core set of paid employees, the company utilizes volunteers to develop the product. Core product decisions are made by the company, however. In a sense, the company is getting its development work done for free under the guise of open source.

Of course, since the product is released as open source, anyone can download and use the product subject to certain restrictions. This means that the development community does in some way benefit from the work they do. But the real beneficiary is the company which ends up with a product from which it can reap revenue from paid support, consultancy and training services. Increasingly, we are seeing cases where the company eventually creates for-sale versions of the software, also known as "dual-licensing". Such is the case, surprising to many, of MySQL. For years a free product, the revenue model finally kicked in and the software became a commercial product. Yes, you can still download it for free, but you'd better pay attention to the fine print. Both the MySQL open source and commercial license pages have language suggesting (at the least) that you should get a commercial MySQL license if you want to use it as part of internal applications within your own company!

Lest you think that such radical interpretation of the GNU General Public License (GPL) would never happen, keep in mind that there were probably many people who thought SCO was a great company to work for or buy from. Just because a company looks trustworthy one minute, does not mean they won't attempt to sue your pants off when their revenue stream needs help. Or, in our merger-prone world, what happens if one of our favorite open source companies is acquired by the likes of HP, IBM or Oracle? If MySQL could consider it possible to require a commercial license for internal corporate use of MySQL, is it really unthinkable that RedHat and JBoss wouldn't consider the same down the road? And if you'd built your IT infrastructure around those products, what kind of position would that put you in? And, even if this turns out not to be the case, will large-scale IT departments really take the risk of not acquiring a commercial license?

As a long-time user of open source software, this Commercial Model is what concerns me the most. I don't deny anyone the right to make money - we all need it. But what I detest, however, is anyone who embraces a movement for marketing or strategic purposes and then ends up doing the same things as the supposed enemies of the movement. This is why I have a problem with JBoss and other such companies. What I'm talking about, in the end, are monopolies.

The changing face of monopolies

Open source proponents like to think of their movement as radical, revolutionary, industry-shattering. And yes, it has certainly changed the face of many IT departments. But has open source really changed the industry or did the industry just adapt to incorporate it? What we have seen in the past eight years is nothing more than a dialectic in action.

Open source sprang up as a reaction to the monopoly of propriety software that was expensive and often slow to change. A company in the 80s, for example, would often end up buying all their software from one vendor, thereby getting "locked in" to that vendor. The vendor software was proprietary and closed - as a user, you never knew what happened inside the black box. Conversely, open source software was open to all for development, viewing and using. You could download an open source version of UNIX from one place, compiler tools from another, and desktop applications from a third. You could fix things you didn't like, add features you needed and redistribute your changes with little or no restriction. The word in those heady days was freedom, and it looked like it had a promising future.

Marxists will tell you that the dialectic is a good thing: out of two opposing principles a third is born, better than the previous two. Both philosophically as well as practically, however, that is not the reality. What really happens is that one side is essentially rebranded as it subsumes the other. Take the monopoly model of the 80s and 90s. Pure evil, to the open source movement. But where did they go? Let's look at RedHat, a leading open source company. They talk about "solutions" and building "an ecosystem around Linux and open source technology". Sure, I may be "free" to pick other software, but doesn't RedHat want what IBM wanted in the 80s? To gently push me into a network of interlocking software and hardware components all under the same brand name? Monopoly rebranded.

Probably most of my readers' hackles have been raised by the suggestion that there is more in common between IBM, Sun, Microsoft, JBoss and RedHat than not. But you have to look beyond the specifics in order to see the similarities. A monopoly in the 80s is not the same thing as it is today. In the 80s, you could create a monopoly by selling hardware that only ran with your software and software that only ran on your hardware. You wouldn't call it a monopoly, of course, you'd call it a "solution". But, like anything, monopolies have evolved. Now we have brand-name monopolies and marketing monopolies. As a developer, I know what open source software is out there and have the knowledge (and so far, the freedom) to pick and choose what I need. But corporate management often doesn't have the perspective that developers do. Instead, what they see are a select number of brand-names promising a homogenous and integrated open source platform. Just like in the 80s, they pick and choose the "solution" that seems to fit their needs. Once they've picked a "solution" or "ecosystem", they are now effectively "locked in". This may not be an enforced monopoly, but it certainly is one in practice.

Obviously, the early open source developers would never have imagined that their movement would someday be subsumed by the commercial model they worked so hard to escape. But that sublimation is taking place before our eyes. In a few years, the open source movement will be characterized by a handful of large corporations essentially owning the monopoly on the IT infrastructure in organizations all over the world. Not much different than the 80s, it is? Yes, the Apache Software Foundation and others will keep on, but I'll be willing to bet you'll see more of their products rebranded and re-released by the open source monopolies. And yes, will continue to have tens of thousands of active projects, but very few will have any kind of serious impact on IT.

In 1997, Eric Raymond wrote his paper "The Cathedral and the Bazaar", generally considered the seminal paper in the open source movement. I find it ironic that shortly after writing this paper, Mr. Raymond was invited to help Netscape Communications create its open-source strategy. I'm sure it was a flattering position for a small-time UNIX developer to find himself in, being invited to hobnob with the top executives of one of the major Internet companies of the day. I'm afraid it was too flattering. While Mr. Raymond saw this as a "real-world test of the bazaar model in the commercial model", it was in reality the beginning of the commercial world's rebranding of itself under the open source moniker. And today, where is Mr. Raymond? He is president of the Open Source Initiative; the same organization that happily applies the term "open source" to companies like JBoss, RedHat, Sun and others. I understand his thinking: you must engage commercial companies in the process of the revolution in order for the revolution to succeed. But that is rather like asking a dragon to light your stove. Sure, he'll light a whale of a fire, but then he'll eat you for dinner in front of it.

The problem of products

The reason why open source is failing is because it never got out of a product-based understanding of technology. When you think in terms of products, you introduce a certain disconnect with reality. Instead of thinking: what tools do I need in order to do this job, you think "which is the best product". This is not how we think in other aspects of our businesses. If you have a plumbing business and you need to fix cast iron pipes, you know you need some sort of a pipe wrench. Given the sizes of pipes you deal with, you can figure out what size pipe wrench you need, go to a supply store, and buy it. You don't think about creating a homogenous and integrated set of tools in your toolbox! You buy what you need and never think twice about it. To put it another way, you deal with individual tools that fulfill individual needs - not "solutions" made up a tool suites.

In the computer world, however, we have lost this practical basis of thinking. We now are constantly engaged in what is actually an abstract exercise in determining "the best". It is a seductive argument - after all, don't we want the best possible database, car or mortgage rate? It is more enticing because we believe that we are being "objective" and therefore highly evolved. In fact, however, we have traded the reality of our own subjective needs for somebody else's subjectivity disguised as objectivity! There is no objectivity when anyone can present a product as "the best". If you don't know your own needs any more, how can you possibly distinguish? The only way is through some artificial means like popularity or price.

Is MySQL better than PostgreSQL? It is more popular - is that the same thing? It has better marketing - is that the same thing? In my business, I need a database that I can link to with my commercial, for-sale product. The MySQL license seems to preclude that. So, MySQL is not good for my business. I choose PostgreSQL. No, it is not more popular, but it works perfectly for me and in fact is technically preferable.

While it may seem a minor point, understanding what your business NEEDS is the critical difference between success and failure in IT. Basing decisions on what you need leads to a mode of thinking that judges technology options based on what works in fulfilling those needs. Anything else and you can always become the victim of a better marketing campaign.

In the 90s I was a high-end Sybase database contractor. In almost every shop I worked in, there was some sort of database conversion. One client moved from Sybase to Informix. Another moved from Sybase to Oracle. Another moved from Ingres to Sybase. Stop for a moment and think: were all those decisions made based on business needs? I'm sure that was the official explanation. But take, for example, a conversion I witnessed in a Fortune 500 company that went from Sybase to Oracle. In the Database Administrator (DBA) shop, Sybase DBAs went home at 5pm and showed back up the next morning at 9am. They had issues to attend to, of course, but they lived a fairly normal life. The Oracle DBAs, on the other hand, were always pulling all-nighters. Their problem queue was so deep it took days to respond to outages. So was Oracle or Sybase a better technical solution? The DBAs would tell you Sybase was the better. But it didn't matter because the corporate management fell victim to a better marketing campaign from Oracle. And that was possible because they lost sight of what was important: their business.

Cost too is part of a marketing campaign, believe it or not. It sounds so grown-up and reasonable to make choices based on pricing. But pricing is all in how you spin it. Most of the database conversions I witnessed in my career were ostensibly based on the fact that the new option would save considerable amount of money. But here again, who says so? Marketers. You can make anything look cheaper on paper. But look down the road a few years. If Oracle requires more DBAs because it is technically inferior, then what does the cost picture look like? Or what happens when the new version of Oracle is released which requires bigger servers? This happens all the time - just look at Microsoft. Any more, new products almost always require new hardware.

The new ketchup

In his paper on their economic model, RedHat co-founder Robert Young addressed the problem of making money in open source. He noted that the success of major brand-name products has everything to do with their ability to redefine a product in their terms. He uses the example of Heinz ketchup, which (at least at the time) owns 80% of the ketchup market. It is not the case that Heinz makes a better ketchup than their competitors; the fact is that Heinz has made their brand synonymous with ketchup. And this is what RedHat seeks to do: if you think Linux, you end up thinking RedHat.

The idea of the brand name is THE American marketing strategy. Create a brand and market it mercilessly. Spend half your revenue on getting that name in front of consumers until indeed, your name is completely identifiable with the type of product you sell. Quality? Whether the product is the best for all consumers? Not your concern and not even an issue in the strategy. If you don't believe me, take a look at the first dozen brand names that come to mind in any industry. Then look at the products from their competitors, the guys running a distant third or fourth. Chance are, you'll see a noticeable improvement in quality or suitability. But you'll never know, will you, if the brand name is always in your face? And if you don't know, eventually, you'll stop caring.

If Heinz marketing can successfully get most of the American market to "choose" their product, so be it. It is a matter of taste, and not so very important in the big scheme of things. But what happens when you turn over your computing enterprise to a brand name? Should you be entrusted by your stockholders to make critical IT decisions when you can be influenced far more easily by a brand name than than your company's business needs? This is what I see happening with RedHat, MySQL, JBoss and others, just like it has happened with IBM, HP, Sun and Microsoft. They are making their name synonymous with open source - re-branding open source. In the process, I fear that user needs will be inevitably sacrificed. Better products do exist outside the brand name; in fact, as a general rule, the better products always exist outside of the brand name club. But if users only see names, those products might as well not exist.

Brand-name thinking creates technology monopolies. In the heyday of propriety software, we can all remember how many an IT shop became locked into a technology direction that did not end up serving their business needs. Just because the buzzword today is open source does not mean that anything has changed. It is just as alive and well as it was twenty years ago. If the open source "revolution" was supposed to change this, it failed. Instead, we are now seeing the emergence of the open source brand names and the inevitable lock-in that they will create. A new generation of an old problem.

Version mania

While I'm sort of portraying the open source movement as a victim of corporate greed, it has its own share of blame. If products are not the answer to business needs, then more products are even worse. In a post to my Geronimo article, a reader asked why the ASF had to reinvent the wheel with another J2EE server when a solid product like JOnAS already had quite a history. It is a valid question, and one I asked a founding member of the Geronimo project at ApacheCon 2003. The answer I got was licensing: the Geronimo team wanted a J2EE server under the ASF license. At the time, I accepted the answer, but I understand the poster's concern. JOnAS is a very good product and one I have used for years myself. Rather than worrying myself about the latest and greatest, I think it is more important to understand the business case for the products and then get on with the business of using them.

This endless cycle of development has a particularly obnoxious manifestation in the open source world: version mania. I have been working with Apache projects for many years. At no time have I seen such short and frantic release cycles as I do today. Look at the 1.3 line of the Apache web server - it took six years to get to version .33. But the 2.0 line has taken only four years to get to .52. Apache Tomcat is another good example: version releases sometimes happen within three or four weeks of each other!

This version mania can have only two effects: product instability and integration nightmares. I remember the early days of the 4.0 line of Apache Tomcat. There were some serious memory problems! If you were so unfortunate as to happen upon the project during one of those releases, you'd be in for a bad shock. And now something similar is happening with the Tomcat 5.5 line. After getting burned a few times myself, I have developed my own strategy: once I pick a solid version of an open source product I stick with it no matter what the next hot evolution is. Only for security updates do I consider upgrading, and only then after a serious amount of regression testing. I'm just glad I don't run a large open source-based enterprise without a well-developed implementation and upgrade policy that eliminates the effects of version mania. I'd probably never get sleep.


I didn't write this paper as a warning of impending danger to the open source movement. I didn't even write it as a prediction. All I'm doing is bringing to light what is already happening and will continue to happen. It won't affect the activities of companies like RedHat, JBoss or MySQL. As more organizations convert to open source these companies will continue to grow and other like them will arise.

All I can offer is advice. If you are a business owner, take a look someday at how much you've spent on technology. Was it worth it? Did you ever subject your technology department to the same rigor you'd expect from your factory or accounting divisions? Did you end up with software tools you could use for decades without having to reinvest because somebody played golf with a new software vendor's sales rep and now wants to switch technologies? If not, perhaps you need to go back to the roots of your business and try to understand what your core needs are. Then find the tools that support those needs. Don't read technology magazines! Sure, new technology sounds sexy. Half of it will disappear within eighteen months. The other half will end up costing you way more than you could ever justify.

If you are in IT management, the best advice I can give you, besides to stop reading technology news, is to talk to your developers. Get to know the people at the bottom of the pyramid - the people actually doing the work. In almost every company I ever consulted with, those were the people who could tell you whether something was going to work or not. If they say a technology is too complicated or buggy, just maybe they know something the marketing people don't want you to know. Think of it as a safety net that can keep you from making bad decisions.

If you are a developer using open source technology, I encourage you to think outside the marketing box. Do a bit of researching before deciding that RedHat or JBoss or MySQL is the "best". They are the most popular and widely-known; that I don't dispute. But that has absolutely no intrinsic relationship to their quality or suitability for your own needs. Take a look at alternatives like Debian, the BSD distributions, JOnAS and PostgreSQL (to name only a few). Keep your eye on license terms, community vibrancy, support options, and, particularly, security and stability. After all, regardless of the scope of your development effort, you may well be building an open source infrastructure for the long haul!

Above all, as I hope I've shown in this paper, it is YOUR OWN NEEDS that you should know best and which should influence your decisions. Be a bit smarter than the competition and don't fall for big names because they are big names or have big marketing budgets. "Know thy business" and you shall know all.


In Part 2 of the paper, The Economics of Commercial Open Source, I will examine the strategies used by commercial open source companies and why I believe these practices are bad for the open source movement. In Part 3, Openstructure: A Call for Open Source Reform, I will present ways in which the open source community can address the dangers posed by these practices.


Addendum: Dual Licensing, MySQL and Monopolies (posted on 1/12/05)

Since this article was published, there have been some comments that open source does not face any danger from the dual-licensing model that companies like MySQL, RedHat and Sleepycat use. It has been pointed out that the GPL is sufficient protection to insure that the source code from these companies continues to be free and redistributable. While I foresee problems with the interpretation of GPL, perhaps those defending the use of GPL by dual-licensing companies will be proved correct. But that is not the point of my article. The core issue that I am bringing up is the emergence of a new class of brand names in technology.

As a developer, I may know that the "Red Hat Application Server" is really JOnAS rebranded. I can go to the ObjectWeb site, download the source code and build JOnAS myself. But my perspective is not the perspective of IT upper management. They don't know things like that. Above the sea of open source options they are (typically) only aware of the big names with hefty marketing budgets. They will see RedHat, for example, and will buy RedHat. They will see MySQL, and buy MySQL. They will implicitly have a certain "trust" in the brand name and a "distrust" for the lesser-known (or hardly-known) distros that repackage the same code.

Any large commercial vendor ends up creating (directly or indirectly) a network of consultancies and integrators that help implement the vendor's software. The biggest names in the system integration world base their business around the biggest names in the commercial software world. And it will be no different with open source. The open source consultancies that will rise to the top will most likely be "preferred vendors" or "partners" with the big names in the commercial open source world. What this means is that if IT upper management looks for help in building an open source-based enterprise, they will most likely end up with consultants recommending the biggest names.

I hope my point is clear here: when I talk about an "open source monopoly", I am talking about an effective monopoly: one created by an evolution of the marketplace in which, inevitably, a few big names dominate. Sure, as a small business I can build and use my own copy of JOnAS and JBoss. As a small consultancy, I can recommend and implements products like PostgreSQL, JOnAS and Debian. But the wave of the future is the brand. And as long as people substitute brand-name thinking for a hard-nosed, down-to-earth approach, they will choose the name. In every other industry, the lion's share of the market inevitably is owned by no more than four companies. It is no different with computer technology and will be no different with open source.

If we want to avoid this fact of life, then we need to revamp our way of thinking about technology and its role in fulfilling business needs. Without a basis in reality, all you are left with is brand names.

The Open Source Monopoly was written by Lajos Moczar, President of Galatea IS Inc. and author of several books and articles on open source technologies. Originally published on 1/7/05, it is now a three-part paper. Part 2, The Economics of Commercial Open Source, and Part 3, Openstructure: A Call for Open Source Reform are now available.

You are welcome to send corrections or insightful comments regarding this article to Lajos at

This article was first published on 1/7/05 with minor corrections on 1/10/05.

References (in order of appearance)
1.. "A first look at Apache Geronimo", by Lajos Moczar. JavaWorld, 12/13/04,
2.. JBoss Inc. Home Page.
3.. Apache Geronimo Project Home Page.
4.. Open source Initiative (OSI) Home Page.
5.. The Open Source Definition.
6.. OSI Approved Licenses.
7.. Apache Software Foundation Home Page.
8.. Free Software Foundation Home Page.
9.. FreeBSD Project Home Page.
10.. Mozilla Organization Home Page.
11.. Red Hat Inc. Home Page.
12.. MySQL AB Home Page.
13.. "The MySQL License Question", by Timothy R. Butler, Open for Business, 8/13/04. The current MySQL license can be found at
14.. GNU General Public License.
15.. Quotes from RedHat come from:
16.. "The Cathedral and the Bazaar", by Eric S. Raymond. Specific quotes regarding Netscape come from
17.. PostgreSQL Home Page.
18.. JOnAS Project Home Page.
19.. "How Red Hat Software Stumbled Across a New Economic Model and Helped Improve an Industry", by Robert Young. Reprinted from Open Sources: Voices from the Open Source Revolution, published by O'Reilly & Associates, 1999.
20.. Apache HTTPD Project Home Page.
21.. Apache Tomcat Project Home Page.
22.. For other articles relating to open source, see: