Slashdot Mirror
Open Source vs. the Database Vendors
bhmit1 writes "BusinessWeek has another spread on open source this week. Among them is an article about open source vs. the database vendors which focused on how businesses are looking to save money with open source (rather than using the source to innovate). From the article: "The databases work fine, but as data volume grows, so do the checks to Oracle, IBM, or Microsoft. Many users aren't clamoring for more features, and some don't even use the bells and whistles they already paid for. They would happily trade some to get their hands on the source code and a better deal." Disclaimer: that quote came from Sony."
Why would I want a small download from mysql?
... which focused on how businesses are looking to save money with open source (rather than using the source to innovate).
Duh. Isn't that the #1 draw for the majority of OSS users out there? Sure there are some that are in it for the politics and others who actually try to contribute, but let's face it, the majority of people use it because it's free (as in beer).
In my work experience, I have concluded that the vast majority of "big name" database users vastly underutilize the features that the big bucks pay for. Many companies that generally only need a step up from MS Access but get sucked into Oracle or DB2 thinking that's the logical next step.
In addition, many database users don't have a realistic understanding of what constitutes a lot of data. I've met quite a few people that think a 10k row database is huge, and anything in the 1 million record range is absolutely gargantuan! To me, anything less than 1 million records is downright tiny. Seriously, many of these users don't need an "enterprise" RDBMS for scalability reasons, which is what leads many customers to open their wallets. Something like Postgres or MySQL would be more than adequate for their needs.
That is not to say there are not users who need the enterprise features, but it amazes me the amount of money that is dumped into features that most small to medium size deployments don't even use.
It is very educational to see how Oracle for example is used in real world deployments. Open source aside, I have seen many where the user may have been better served by just using a properly setup MS Access or FileMaker database!
-Pete
Soccer Goal Plans
It may surprise you but most people who use open source applications do not change the code. Even the ones who know how too, don't. Why, because they don't have the time. They download it try it, if it does what they need they use it, if not then they try an other product, if they cannot find an Open Source tool that does the job then they see if there is a commercial one that does. Programming takes time, even an open source application, time costs money, so if paying 2k for MS SQL Server vs. 3 weeks of development, to get the functionality they need they will just get MS SQL and they will save money. Plus this time could be used by the programmers to create business critical code (Which earns $$$), vs. IT Infrastructure code (which costs $$$, but may save $$$$ in the future). As some of your open source developers may or may not realize your cool feature may not be used by anyone buy yourself. Heck I have a hard time to get people to used Stored Procedures in their SQL, needless to say trying to get them to use the more advanced features.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Well large is subjective. To a small company 10k of data is large. And when someones sells their apps for Large Database they jump on it because their database is big for them. Even though they would be better off with the smaller Database server because the algorithms are based for processing smaller values.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
A company such as SAP (SAP) could be pivotal. The German software giant is locked in an applications war with Oracle, but the bulk of companies running SAP applications run them on Oracle databases. So even when SAP wins an application deal, it's often making money for its archrival. That doesn't sit well with ultracompetitive SAP, which already has a burgeoning partnership with MySQL. Closer ties there could mean more SAP applications on MySQL databases. Elsewhere, Red Hat (RHAT) has endorsed both MySQL and Postgres, as did Sun Microsystems (SUNW) last November.
So Oracle has now become Microsoft, pretty much resting on its laurels and claiming that its users are more than happy with them, while all-the-while, their users are shopping for cheaper and better solutions. If SAP were to out-and-out declare they like MySQL better and shift most of their DB usage there, Oracle would have a very large amount of egg on their face.
Let's face it: when you become the dominant leader of your industry, you tend to forget what got you there and you take it for granted you will always be there. I've used Oracle, MySQL, and Sybase, and I find the latter two to be a lot easier to work with than Oracle. Oracle is trading solid dependability for tricks and gimmicks, and in the end, no one wants to pay that kind of money for things they don't need or won't use.
GetOuttaMySpace - The Anti-Social Network
I'd love to develop my apps with Postgres, then deploy to Oracle or DB2 with an automated tool. If Oracle or IBM distributed a free (beer) one, I'd include it in my project plans. And if there were an open source tool for comparing performance of my app on each of those databases in real tests, I'd be more likely to make the switch - provided the tests showed an advantage.
--
make install -not war
Then there was that one Java project, where the database schema mapped directly to the inheritance hierarchy of the object model. Booting the application server took longer than booting the operating system. While no raging Java fan, I can't help but think that particular issue was coder ignorance writ large. Wrote the test plan, got out of that swamp ASAP.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
From the article: They would happily trade some to get their hands on the source code and a better deal.
How many are there who would actually look at the source code of a database, work on it rather than develop new applications based on it? If database A works, then they are going to stick with database A until conditions change drastically. It hasn't happened now and doesn't seem like it will happen in the near future.
You're a little bit off there. To a company with very little data, 10K of data is large. There's nothing saying that a small company can't handle lots of data if they do it in an organized manner.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
The user says "This is vital". IT staff start adding zeros to the price tag of the application. Seriously nobody in the IT dept is ever going to suggest something like mysql or postgresql for something like the corporate accounts or other financial transaction backends because people like IBM and Oracle guarantee that when the power goes out, the transaction completed, or it didn't happen at all.
And if you've paid for Oracle/DB2 and you're training your staff on and using Oracle/DB2 anyway then it doesn't make a load of sense to introduce different RDBMS systems that your DBAs and administrators are completely unfamiliar with, especially when you've got that Oracle box sitting there underutilised.
Ultimately you're right, 95% of apps could be served perfectly well by mysql, postgresql, msaccess, filemaker etc. Corporate IT depts should really create two categories of RDBMS systems, vital and casual. The vital ones being the core business operations and casual being everything else.
Deleted
I think most businesses crave accountability & reliability more than anything.
I'd be more comfortable running a system running a vendor dbms rather than an Open Source implementation - just because when shit hits the fan (which it invariably does), at least there's ultimately someone responsible for it.
Don't get me wrong; we run mySql for all small-midsize operations, but the bigger systems run Oracle purely because of this reason.
throw new NoSignatureException();
Sometimes, it is an attempt to get the greater reliability that is frequently attributed to the "big" systems. Justified or not, RDBMS like Oracle or DB2 have a reputation of being less prone to crashing or data loss.
This said, I would probably go for somthing like Postgre or Firebird myself. But NOT Access, I've heard from our service department that the Access databases of a certain device tend to crash when they grow beyond 1 GByte.
C - the footgun of programming languages
A more appropriate and true statement is: to a company whose largest database numbers 10,000 rows, 10,000 rows is a lot of data. But that's trivially obvious.
I think it depends upon the scale. There are probably many small users out there looking at OSS databases to save money on licensing. And these types will be very happy to jump on board to a 'free' proprietary product. But there are some large companies with the resources and the desire to leverage access to the source code. A good example that comes immediately to my mind is Fujitsu's involvment with PostgreSQL.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
I agree 100%. I have worked on plenty of development jobs where management wanted to use SQL Server (normally) or another big name database because they thought they had a lot of data. Typically we were storing a few hundred products and maybe 10000 orders. I voiced the opinion that that wasn't much data and an OSS database such as Postgres or MySQL would easily handle it. I've never recieved such dirty looks. I think the managers want the prestiege of using a "real" database.
I used to have a better sig but it broke.
This is a surprise? Maybe "back in the day" innovation was a significant part of the average business plan in the United States, but those days are long gone in today's business world where short-term financial gain is the only objective. Realistically, the only innovation going on today it that which is related to military use. Sad, really.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
Databases that fit in this description since a long time are: Oracle, MS SQL Server, DB2. New on the list are: MySQL, PostgreSQL. Wikipedia link: List of RDBMS
And maybe some will be added to the list in the future, like Firefird, and who knows H2.
Google Adwords uses MySQL.
If we use an open source app my boss will have no one to call up and shout at when things go wrong. Thus, any suggestion to use an open source DB will be pissed on.
Ease of use is important as well. Or maybe not (see Oracle).
At my company we are making a move to MySQL in order to accomplish what SAP cannot do for our assembly lines. This involves keeping track of incoming and outgoing material. SAP will still keep track of what happens with the finished goods, and received parts. Why we keep SAP probably has something to do with the corporate jacuzzi.
I wrote an application like that once (I was young and foolish). But I'm better now, I swear (we spent most of summer removing that, and a few other screwups)...
This, and also because OSS is a way to avoid lock-in marketing techniques used by non-beer software providers.
Enterprises, specially, are not intersted only because it's free (beer) for them to use an opensource software, but also because it'll still either be free or damn cheap to switch to something else that better suits their needs,
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
It is not IT's job. IT just gives everyone the pricing based upon how many 9's of availablility you want and the database/server licenses.
If the user balks at that, the database can be put on the far less expensive PostgreSQL/mySQL server.
The downside is that the database people need to become familiar with TWO different databases (or more depending upon the other apps).
The upside is that the company saves a LOT of money in licenses and such.
This isn't just a Java problem.
Mapping the Database hierarchy directly to the java class files is not necessarily a bad thing. It becomes a bad thing when you try to load and access it. :-P Meaning that you have to be careful and consciencious about how you manipulate things and where your transaction/session boundries. The use of entity beans is the greatest offender of this, followed by hibernate abuses. At long as you do not manipulate, or perform a minimun amount of manipulation, (like inserting primary and foreign keys), within the transaction boundries. It can become very efficient, depending on the design of the database. But if you are slopppy one mistake and your performance will crater.
My gripe is when people create 2 sets of nearly identicle class hierarchies, one to map to the database, one as data transfer objects, then proceed to copy one tree to the other everytime they hit the database. The more I see stuff like that the more I wonder why not just use JDBC, or Spring JdbcTemplate.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.
Correction. You misspelled MS Foxpro.
The real advantage to taking the business logic out of the db is: scalability. The db will always have much more limited scalability than the middle tier. It's much easier and less expensive to throw more app servers into production, than it is to throw more db servers in.
"Crude and slow, clansman. Your attack was no better than that of a clumsy child."
Phooka.de (302970) wrote:
The problem is right now none of the relational database management system vendors follow a common syntax for these kinds of advanced features. The SQL 2003 standard specifies the proper syntax for stored procedures and stored functions, yet the actual implementations diverge with their own SQL dialects (Oracle's PL/SQL, Sybase and Microsoft's Transact-SQL, etc.). Not even MySQL follows the standards to the letter (for example, AUTO_INCREMENT is not the standard way to create an automatically incrementing field of data).
After taking my first database class for computer science, I was truly shocked by two things: this lack of standardization support (no doubt to encourage vendor lockin) and the sheer kludgery of SQL syntax.
On vit, on code et puis on meurt.
The real advantage to taking the business logic out of the db is: scalability. The db will always have much more limited scalability than the middle tier. It's much easier and less expensive to throw more app servers into production, than it is to throw more db servers in.
Yeah, but updates should still be propagated to all the other app servers, leading to the same basic problems as in the lower tier. I have to think that the only reason the middle tier is more scalable is that the data integrity standards are lower.
I recently blogged about a talk given by Greg Stein (a googler) where he briefly discussed why they use mysql
Of course, this is a problem for Oracle. Building Larry Ellison's house cost far more than MySQL generates in profit. I drive by the place all the time. Under construction, it looked like a mall. Oracle stock dropped from $50 to $12 while the house project was underway.
We use MySQL, Postgres, SQL Server, Oracle and DB2.
Out of all of these product, the best DBA we have is an Oracle guy. He really knows his stuff. It is the smoothest and easiest to program for because he can answer the questions we ask. He's also a really good programmer, so he can debug the stupid mistake done by the contractors(Ok, I might have made some dumbass stuff myself).
If I had my choice, I'd use Oracle everywhere and promote him to manage it all. He has shown me that no matter what you use, it;s only as good as the support you get from your DBA.
Absolutely right.
The database is almost always the limiting factor- you can chuck in more web servers easily, but to expand the DB gets very complicated very fast.
Even when you work with decent mainframes, as I do.
http://blog.grcm.net/
This, and also because OSS is a way to avoid lock-in marketing techniques used by non-beer software providers.
Isn't it really the other way around? If you choose say PostgresSQL and then go in and make heavy mods, haven't you just locked yourself into PostgresSQL? Perhaps even deeper than you might have if say the source were not available to you (so you had to work around it). Let's say the Postgres guys decide to adopt GPLv3, if that causes problems, you are either stuck with the older non-v3 version, or you have to move to something else. How is this any different than vendor lock?
Few people know to interact with a database efficiently. http://www.ncr.com/en/solutions/solutions.htm takes this to an extreme but with a good db design you don't have to worry about scalability. It might take a little time to figure out what to index ect, but unless your over 10k transactions per second there is no reason to worry about scalability. Chances are performance issues are based around your design and using the db more will help. This is not to say that cashing is without value, but with proper indexing SELECT can be insanely fast on multi million record tables.
PS: This is not to say all systems work well with a huge db on the back end but when you look at the total costs of doing this stuff in house even Oracle and 50k in HW can seem cheep.
I don't work for a database vendor but I find some comments above about open source databases optimistic. MySQL is fine for small and mid-size companies but I don't see large corporations letting go of commercial database products any time soon. Even if they've never heard of OLAP or Grid databases they will most likely choose Oracle or SQL Server over MySQL any day.
.NET and Java projects), but I've used DB2, SQL Server, MySQL and PostgreSQL. If you think Oracle is not user-friendly try using TOAD or DBArtisan - both are fantastic.
Here are some costs associated with open source databases which you may not have thought of:
1) No Support - what happens if your developers run into an issue with the product or your production system goes offline. Who do you call for support? Who do you call accountable for project failure (worst case bankruptcy)? Nobody wants to resort to online forums.
2) There are many Oracle, SQL Server and DB2 specialists on the market. Finding a MySQL expert for support staff is much harder. You need years of specialized work experience to be an expert.
3) As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes. It's easier to follow someone else's success then wandering around on your own.
P.S: I do most of my development work with Oracle (with
So you store the business rules as data in the database and control your middle tier through the data. The rules are still centralized but the processing is not.
A Pirate and a Puritan look the same on a balance sheet.
The open-source RDBMSs *are* catching up to the closed-source databases, but there is still plenty of work to be done. One area in particular is support for the XA protocol for 2PC.
Both of the "big two" (MySQL & PostgreSQL) advertise XA support, but neither has complete support; as both fail to support suspend/resume. And while this might seem like a minor point, XA support is an absolute must if you want to do something like incorporate a database write and something like a JMS message into one transaction. Currently you can't do that with, for example, JBoss and PostgreSQL, as JBoss' transaction manager tries to do a suspend at some point in the process, resulting in an exception from the PostgreSQL JDBC driver. (As an aside: I haven't researched yet whether or not this is correct behavior by the TM, so this particular example might not be a problem with a different app server).
Clearly not everybody needs this level of functionality.. but for those who do, it's critical. By way of example - imagine an enterprise CRM system which uses JMS to federate data across systems by publishing events to a Topic when customer records are modified. You really need ACID compliance for both the database write and the message publish, or you get inconsistent data which is BAD, BAD, BAD. Yes, yes, I know there are ways you *could* get around this without using XA, but the point is that this is what XA is for and this is the direct, obvious, normal way to approach the problem. And by and large, the open-source databases just aren't there yet with the needed functionality.
That said, I believe they will get there in time. And in fairness, there may be a open-source database (possibly Ingres or Firebird) which does have full XA compliance, I haven't investigated them all in detial.
// TODO: Insert Cool Sig
Some helpful hints, if you are interested in writing better:
You wrote: On the other hand; If your database[...]
Problem 1: you want a comma, not a semicolon (the semicolon usually joins 2 sentences that *could* stand on their own, but are very closely related, or it's used in complex lists as a sort of strong comma).
Problem 2: Why capitalize "If"? You're still in the same sentence. You aren't in a new sentence until there's a period, question mark, or exclamation mark.
You wrote: [...]downtime can cost your business it's life.
Problem: "it's" is a contraction for "it is". Always. Anytime you see "it's", try replacing that with "it is" and see if it works. Here, you want to write "its".
You wrote: [...]if [...] can cost your business it's life. You would be a fool not to use it.
Problem: The first part (with the "if") can't stand by itself as a sentence. It's like writing "If I knew at the time." You need the second part of the sentence to complete the thought: "If I knew at the time, I wouldn't have said that." The second part could have been a sentence on its own, but not the first part.
You wrote: [...]our most critical and complexed applications run Oracle.
Problem: Typo? You mean "complex".
You wrote: Why? Because the only way you will lose data in a Oracle database is if you shouldn't be managing an Oracle database.
Comment: You *technically* shouldn't start a sentence with "because" (this is another dependant phrase), but it's common and probably okay in casual writing.
You wrote: C_Kode
Suggested replacement: C_Code
(heh heh)
Granted some non-widely used software will only offer forums, chat, and lists as support options. But most major open source packages (including MySQL) does have professional level support available. Some open source companies (like MySQL and RedHat) offer commercial support themselves directly to the customer. Other packages have vibrant support communities that have sprung up around them and even companies that are quite successful offering commercial level support for several open source packages.
Saying that the reason people don't switch to open source software is because there is no support available is simply not true. It might have been true two or three years ago but not anymore. Take some time and investigate your options and you'll find there's a lot more available out there than you might think.
Anthony Papillion
Advanced Data Concepts, Inc.
"Quality Custom Software and IT Services"
They probably were using the wrong type of database. Object relational databases offer object oriented languages the same advantages as ISAM offered purely procedural languages (Cobol, fortran...). Relational offers advantages that are different (like data integrity) but there are real legitimate issues where you programming language internal memory strctures to look a great deal like the structures as stored in the database. Particularly if the quantity of data is huge (for a modern PC something like bursts of 100 Mbits / second sustained for 20 minutes or so).
You misspelled "hell no".
The problem with FoxPro is that people come to depend on it, and start building their internal applications around it without realizing that it doesn't scale.
I don't mean that it doesn't scale well, but that it simply doesn't scale at all. Since it's not a database, but a single-threaded client app that reads and writes files off a fileserver instead of making remote queries, doubling the number of users doubles the amount of network bandwidth you have to use. If twenty people are accessing the same 1GB "table" concurrently, then heaven help you all.
My company depends on a FoxPro app. Without it, we go out of business. I was hired to write a web application to allow customers to access our FoxPro data, and ended up having to write a hideously complicated n-tier system where we have one VMWare image for each concurrent query we wish to be able to run. Yeah, you read that right: since the FoxPro client libraries are single-threaded, if we want the ability to execute 10 simultaneous queries, then we have to run 10 load-balanced VMWare images to service them.
So, I eventually wrote a system to copy the table files onto my local system, use a modified version of the xbase package to render them in PostgreSQL's "copy from" format, and them load them onto a pgsql server. It's more complicated in some ways than the native FoxPro query setup, but the upshot is that our queries now run between 100 and 1,000 times faster on average. Yes, those numbers are from actual profiling runs. Some queries that used to take 60 seconds (!!!) now run in a few milliseconds.
If FoxPro is the answer, then the question needs to be taken out and shot. It has our company in a stranglehold and we're doing everything we can to get out from under this twisted nightmare from hell. I honestly think you'd be better off writing applications in Excel, and that's not something I'd say lightly.
Dewey, what part of this looks like authorities should be involved?
Whoever you paid for your commercial MySQL or PostgreSQL support contract, of course.
There are many Oracle, SQL Server and DB2 specialists on the market.
So your contention is that a high rate of turnover in the support of those applications is good?
As an early adopter of software you take on the risk while others (including competitors) learn from your mistakes.
MySQL and PostgreSQL were publically released 11 and 17 years ago, respectively. If that's your idea of "early adopter", then may I also suggest other hip new technologies you might wish to investigate, such as TCP/IP, VGA graphics, and transistor-based memory?
Dewey, what part of this looks like authorities should be involved?
No company with a board of directors is going to bet the farm on a mission critical software product for which they cannot purchase support. You have to have someone to blame when everything falls over.
"Crude and slow, clansman. Your attack was no better than that of a clumsy child."
Well you are skipping a few other features that some might find useful such as Java integration or .Net in the case of SQL Server 2005. More scability options. Also it may be easier to find qualified DBAs for the big name databases, you can never underestimate the cost of labor.
Maybe it makes a difference in the dbms & environment you're using, but I'm sure if you do some application profiling you'll likely find that time saved on parsing by using stored procedures is minimal.
I've recently scaled an app up from 30 concurrent users to 1300 & we don't get the slightest performance problem from the network traffic of passing SQL (this is minimal compared with the traffic of dragging the data to the application), nor do we get any performance problems from the time taken to compile/interpret the SQL statements (all the major dbms's will cache the query plans anyway).
The places where you get performance hits are poorly written queries, bad indexing, and row-at-a-time processing from programmers who don't understand how to program relationally.
My policy is to use stored procedures only for main business transactions (eg add/update a customer) and for actions fired by triggers. I find that it's pretty irritating to have to go and dig out a bunch stored procedure definitions whenever you want to see what a programs doing. When over used they obfuscate rather than clarify.
Agree with the other comments tho.
May Peace Prevail On Earth
Oh - I've seen it done correctly - actualy I 've also been a bit part player in making it work correctly as well :D
But like you and others, I've also seem to many done badly enough that they slow a machine to a crawl while it's either loading the application or crunching big datasets.
Ingres has full support for XA.
Access databases start running into issues at around the 1GB per MDB mark. (Pretty sure the max size is 2GB... I think... I should know this dammit! Meh, we always split into multiple MDBs in those cases.)
Where the Jet database engine (which is what MDBs are the datastore for) runs into trouble is concurrent access. Take a web server, use a MDB... at around 30-50 users you'll start running into severe performance issues. Switch to SQL Server / PostgreSQL and that same web server can now handle 300-500 users.
MDBs are still handy for small, portable, mostly-relational, isolated pockets of data that need to be passed around. I do wish there was something better (OOBase might replace MDB in a few more years).
Wolde you bothe eate your cake, and have your cake?
To the extent they exist, are free, functional, and that people actually pay attention to them, standards will help make a smooth transition for customers wanting to trade Brand X SQL server for Brand Y SQL server.
I'm not sure how many customers actually migrate downward from a commercial offering to FOSS options like MySQL or Postgres. Upward migration has always been a way out if you outgrow the FOSS, but you can always evaluate whether the increased performance, reliability, features, support are worth the money. That means vendors get their feet held to the fire to provide genuine value-added.
It means it will be increasingly difficult to sell plain old SQL servers to new customers if the "Good Enough" MySQL and Postgres become increasingly capable and set the bar higher and higher every few years.
"Provided by the management for your protection."
(As mentionned before on this thread, the commercial companies are seldom interested in modifying heavily the apps. Maybe bugfixing, or designing a couple of plug-ins but that's everything. And in rare case of heavy mods, if done correctly, the company has a team of programmes working on them, and they could try to port the plug-ins to whichever new plat-form is chosen).
Vendor lock :
- You were moronic enough to develop an application running on MicroSoft Access (I've actually seen such cases). You're stuck between update or keeping the old version.
Standart compliant software :
- You depend not on specific software solutions, but on you own data and the specific interfaces/standarts/formats, etc... which are open. So you can either switch to whatever else software which complies to the same standarts (Almost all non-Microsoft Office software support OpenDocument format. SQL provides to some extent a common ground accross database software. Language like Python, Perl, etc. are widely supported on a lot of plateforme but VisualBasic is not. etc.).
OTH: Vendors, once they have a big enough user base, are btter interested in developping solutions that DON'T let the users easily run away to something different.
Or you can export/import you data, and you can always manage to create (or most likely find some one who's already done) a converter / data extractor, because data format are open and you still have the source code to start working with (In the unlikely event of the GIMP team stoping to work on this software : its format is documented, source code reading it can be found from the software it-self, so a converter is likely to be doable and was probably already done).
OTH: Unless you sign a NDA it's harder to have access to inside mecanics of a non-open software and reverse engeneering is required to try to make the data extractable.
Or with a big enough team, you could pick-up a stalled project, or fork and keep developping what you need. (There are a lot of abandonned open-source projects which where continued by others, because there was interest among the users. And there are exemple of forks because developpers want to go one direction and other users needs another one : see Sodipodi vs. Inkscape. There can even be collaboration between the forks or parallel projects : see Gaim and Gaim-VV and Adium, or Wine and Reactos, etc.)
OTH: Unless you buy the company and/or the IP assets you cannot "fork your own" easily.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]