MYSQL and RDBMS [closed] - mysql

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm having difficulties to answer this question. Can someone help me?
Discuss the benefits of MYSQL and explain why it is gaining acceptance as the RDBMS of choice for many organizations worldwide.

Because it's free (or historically has been free) and gained critical mass on the on the open source platform stack earlier than its competitors (e.g., postgresql).
Due to classic network effects in software, and rdbms is valuable not just in itself but also its userbase, especially so for OSS where users can contribute back. This is why critical mass is so important.
Network effects in any product are classically observed to cause a "snowball effect" or self-fulfilling prophecy where popularity fuels further popularity. This can ensure the dominance of an early successful product despite any technical flaws it may or may not have. Additionally, rdbms customers are highly conservative (DBAs are loathe to putting anything in production that hasn't been out for very long) and switch costs between rdbms' are significant for any development team, due to innumerable subtleties of their use and operation.

Here are benefits of using MySQL (link)
Also, a more throughout lecture (link)
And wiki (link)

MySQL is fast, free and open-source. It is easy to get up and running, has a good API in many languages and several inbuilt scaling options (replication and recently partioning).
In addition, it has very good marketing :)

Try asking Sun Microsystems for their opinion on MySQL.

MySQL is light, easy to use and has an excellent worldwide community that is very active. An active, vibrant community indicates a certain acceptance by your peers and I think is a very good indication of a product's position in the market. I, personally have had almost immediate answers to any queries posted on the MySQL forum.
Post, the acquisition of MySQl by Sun, it has gained even more traction and recognition in the industry. Depending on the type of support you want, you can opt for commercial versions of MySQL.
These are my personal views. I'm pretty sure you can get a lot of links on the web detailing MySQL's myriad features.

I think it depends on the size of the organization as well. I would not say that MySQL is gaining worldwide acceptance. Most large corporations (Fortune 500) are still gun-shy about open source software and would prefer to pay for support.
The new service model that's being employed by open source companies, like Spring Source, JBoss and Red Hat, and MySQL from Sun, helps a great deal.
But it hasn't opened any flood gates. Most IT managers know that they won't lose their jobs buying from IBM, Microsoft, and Oracle. They'll complain about the license fees, but they're still worried about open source.
There's a two-tiered adoption model: large and small. The large companies feel comfortable with IBM, Microsoft, and Oracle and mainstream languages like C# and Java. The small companies can take a shot with open source and Python, Ruby, etc.

While the network effect is why MySQL remains popular, I think it gained its popularity for two simple reasons: it is free which makes it ideal for cheap webhosts to provide to their cheap web admins; and it is good enough for most tasks one would use a cheap webhost for.
MySQL didn't climb into prominence in the IT back office. Webhost providers for the toy website users needed a database offering. Before there was myspace and facebook and livejournal would be web site makers would roll their own using the cheapest website provider available.
The synergy with PHP's own rise to popularity is probably not insignificant either. But that's an unnecessary digression I suspect.

MYSQL is not always free. If you intend to use it for commercial purposes, a license should be bought (link1 link2). You may want to double check.
You are not forced to buy a license but it is recommended. Open source software development does not always come free of cost.

Related

Who pays developers of open-source software? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
We are facing a lot of open source software.
But someone needs to write that software. How are they payed?
Do you know a good article about the open source politics and economy?
Sometimes the big companies themselves release open source because they have some benefits.
Then they sell support, advices ...
My question is what is the real economy about open software?
No professional will work for nothing. This software are couple of classes but thousand or may be millions of classes. If you are really a pro you will write software for money, because you have life, wife, kids, taxes, you must earn.
Please do not tell me that they are doing this for pleasure or hobby!
On Stack Overflow, we get a lot of good quality answers (and questions).
But somebody needs to write the answers. How are they paid? Surely no professional would spend time hanging out here and answering questions for nothing.
...
This, of course, is not how it works: people get pleasure from contributing to something, from testing and extending their knowledge, from being part of a community. Thus they write for SO in their spare time, and enjoy doing so.
Free software is no different.
Eric S. Raymond wrote The Cathedral and the Bazaar and other essays about this, and these are probably the best place to start. There's also a Joel on Software essay somewhere with some good points.
Some people write free/open source software because it's something they personally want. Some do it as part of a reputation game, similar to academia. Some people get paid for it.
Companies pay for it because they make money off it somehow. O'Reilly Books makes money by selling books on using free software. Red Hat makes money by providing enterprise-quality support. Apple makes money by adapting it to their needs and selling computers using it. I think IBM is working on Linux so they can slowly move away from AIX. Some companies find it more economical to develop free software in conjunction with other companies, so everybody can use it and nobody has to pay too much.
Companies that make their money selling software, like Microsoft, will generally avoid free software. Companies that make their money on something related to software will want the software as cheap as possible, preferably free. In some cases, this means software the customers use, and in some cases this means software for internal use.
Most of what I've done on FOSS projects has been unpaid, either building a tool or some functionality that I need at the time - "scratching my own itch", as ESR puts it. This doesn't mean that it doesn't make me money. As a freelancer, the tool I build/improve today could help me land a project tomorrow or help me get an existing project done more quickly, either of which is good for my bank account.
Back when I was working as someone else's employee, there were also times when I developed code on the clock that would help with my job, or other employees' jobs, but my employer wasn't in the business of selling software anyhow, so they were willing to let me release it under a FOSS license.
Today, I offer clients a discount on work done for them which will be released under a FOSS license, in which case I would be getting paid directly for work on FOSS code. Nobody's actually taken me up on it yet, but a current client has asked whether certain parts of their project would be suitable for open sourcing, so they're clearly open to such arrangements and looking for an opportunity to get that discount.
Edited to add: Freelancing has not been kind to me in the six months since I originally posted this answer (too hard to find paying clients for my language of choice), so I have accepted a full-time job with the local university's library, where I will be helping to clean up their in-house collection management application so that it can be released under a FOSS license sometime next year.
So, yes, there are jobs out there where writing FOSS is the primary job responsibility. I suspect that they're mostly in the public sector or at educational institutions, but there are also some private corporations (like, say, Red Hat) where such jobs can be found.
When you say "professional", by definition you are establishing the value and compensation context of your question/statement. But software is not just created as an outcome of the fruits of a profession. Software is art. Some writers have to write, some painters have to paint. Coders need to code. We all acknowledge that it would be nice to be paid for doing what we are. Some are better at it than others is all.
Look at Linux, MySql and many others. There are huge corporations behind the most successful projects, so people will work there as they'd do for any other employer.
A detailed discussion here: http://news.slashdot.org/story/10/04/27/0048250/Why-Making-Money-From-Free-Software-Matters
Most open source software work is done completely unpaid.
Some open source software is useful enough that a company that would benefit from the software being better will "donate" developers to work on it. For example, RedHat - who markets a paid version of linux - may pay for developers to improve certain parts of GNU Linux.
Some open source software has paid support, or paid consultants. So, MySQL was free, but also offered professional consulting based around the software they were already experts on.
But most open source work? Unpaid. Normally, it's a great thing to put on a resume to get you a paying gig.
I am currently working on several open source (GPL) projects. Pay comes from various government grants via the local university.
I found a good article: The simple econimics of open source by Josh Lerner:
My guess:
60% of open source development is
done by developers payed by
corporations
20% is done by developers which like to learn and improve (also having in mind their day jobs)
10% is done by students to learn, or as assigned works for university projects
5% is done for a better world (open source corporations like Firefox)
5% is done for games and fun
Usually nobody unless you work for Mozilla, Google, Yahoo, etc.

How to retain the rights to sell an open-source project at a later date? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
I'm in the process of starting an open-source project aimed at digitising a whole bunch of forms provided by a government department. Basically at the moment if people need to fill out the forms they need to do so on paper, and I'd like to change that so that it can be done on the computer.
At present, the project has no official affiliation with the government and I'd like to set it up in such a way that the public can help contribute to digitising the forms as there are a large number of forms. At some point in the future, the forms may come to be of a standard where it would be feasible that they could be used officially by the government. If this were to be the case, it would be ideal if there was some kind of remuneration, rather than the forms being handed over to the government free of charge.
In such a case, how do you retain authority over where the money goes, given that the project could potentially have had many contributors? Obviously I would like to pass on remuneration to contributors that is based on how much they have each contributed, but is there any legal provisions or statements I would need to have in place to retain the authority to be the person that makes the decisions about who gets what? Is it a simple case of "person that starts the project gets to decide", or would this be in breach of any laws surrounding intellectual property or copyright, given that part of what is sold would be other peoples contributions?
A case (on a much larger scale) similar to mine that I can think of is with Sun buying MySQL - who got to decide where the money from the sale went to, and what did they have to do to retain the authority to make such a decision? As an asides, what did Sun actually get out of purchasing MySQL that they could not have had by simply downloading it, given that it was open source?
Sun, I'm sure, had lawyers. I really suggest you talk to one. They would be able to sort out how to retain some kind of rights over the money so that you (and your contributors) could get remuneration later.
Even open source projects have the concept of copyright.
The code of the project may be open-source but the copyright belongs to someone.
For example most GNU programs belong to the FSF. If you make non-trivial contributions (more than simple patches) they will ask you to give them the copyright of the code.
I suspect this also happens with other big open-source applications (e.g. Mozilla, Eclipse e.t.c).
The controller of the code (and where the money goes to) is the owner of the copyright.
To solve your problem you just ask all contributors to sign papers that assign the copyright of the code to you.
If you later decide to do something else with result you are free to do as you wish since you will be the soler owner of everything.
InterBase is a database system that was branched to an open-source version. Today, it's closed-source again but other developers are continuing to develop the open-source version. The two products are becoming very different nowadays but they have been very similar in the past.
The problem is that the open-source license will stay with that specific source version forever and ever. You can continue to develop your product, adding new features and changing it back to a commercial product again but you would be competing with other developers who might continue to develop on your open-source version. And they hold the copyrights of the modifications they're adding to your project.
Your main problem with turning back your open-source project to a commercial version again are the contributions from other open-source developers. If they gave you feedback and added code to fix certain issues then those changes are copyrighted by them and you can't add them to your commercial version, unless your commercial version continues to be open-source.
Still, a product can be open-source and commercial! Several Linux vendors make big profits doing just this. The profit is from the support they give to users, who are willing to pay for this support. They're not really selling Linux, they're selling support and their services to create an easy-to-install Linux version.In your example, you can't turn the project back to closed-source since you're accepting contributions from others. Those would all fall under the open-source license. But you own the copyright and the (trademarked) name, thus you can determine if people can offer commercial support for your product or not. They might have to pay you to use your trademark! The value is not in the code but in the name...
To contribute to OpenJDK, you have to sign a paper that transfers ownership of your code to Sun.
Providing an infrastructure for signing such a form would be a nice start for your digital form management project ;-).

Pros and cons of building apps with proprietary database systems

I've been interested in 4D SAS' database product for a long time, though have barely touched it in eons.
In considering what tools to use for application development, especially one that will require a database component, what should be looked for when considering open-source tools like MySQL and PostgreSQL vs proprietary solutions like 4D or Pervasive SQL?
What good (and bad!) experiences has the SO community had with various DB tools like 4D, Pervasive, FilemakerPro, etc?
Any bad experiences?
Difficult to make a relevant list of Pros and Cons without a context.
My advice would be the following: when making the decision of using a proprietary database, make sure that this decision is based on strong facts and not merely a technical interest for an exotic tool. Put into the balance the benefits for using the proprietary database and the advantages of a non-proprietary solution.
The answer is different from system to system.
A prerequisite is that your system is well identified, with a clear scope, a quite predictable evolution, so that the results of your analysis will be robust. Then, if your proprietary solution brings a real benefit for your system, that you are comfortable with the support and that you can afford the overall cost, you should be a good candidate for the proprietary solution.
4D is a MacOS/Windows only cross-platform, proprietary database system with both stand-alone and Client-Server varieties. You would do well to compare it to Alphafive.com software which is Windows only. I've worked with it for 17 years and it has served me and my department very well. Off the top of my head ...
Pros:
Interface & code are closely tied to the data engine which makes development of rich, cross-platform user interfaces very fast and easy.
Proprietary relational data engine runs natively on both platforms, along with native client interfaces (but requires licenses for multi-users). Auto-relations are helpful (but sometimes get in the way).
Can access external systems via SOAP and ODBC and SQL drivers (limited).
Can access 4D from external systems via SOAP or http requests & web pages.
Native procedural programming language based on Pascal and is EASY to learn.
Excellent tool for small to mid-sized departments.
Latest version accepts subset of SQL commands AND original data access, so it's backward compatibility record has been very good.
Security is EASY in 4D.
You can build solutions to deploy through a variety of means, and are not limited by whether or not MS Access is installed.
Cons:
Interface & code are closely tied to the data engine which can lead to limited use of abstraction and "black-box" coding unless you make it a goal of your development.
Compiles to one monolithic structure file forcing restart for single fixes.
Language is still only procedural--making it harder for object-oriented programmers to accept. Every method requires separate "file" in 4D so you can't include more then one function or procedure in a single routine -- it will take some getting used to it.
While company appears to be in good shape, growing and developing, you simply never know as they keep their condition to themselves.
Company has never really marketed itself--trusting in its developer base to spread the word and grow the product through site deployments and product upgrades. Web site is clearly useful only to developers who already use the product -- it simply fails to attract new users.
Product upgrades have always seemed to focus on how the tool is better for the DEVELOPERS rather than for the CUSTOMERS of those developers.
SQL lacks views, compound indexes, and other common SQL features.
When a user requests a report of specific columns of data, I often have to write yet another program just to provide that specific data -- I can't always just query the data and generate a text file.
Does not handle new OS versions with nearly the ease of web browser based applications. Older version is broken on Mac OS 10.6, and newest version requires the latest Mac OS 10.6. No version is certified yet on Windows 7.
I've been nearly a year at learning ASP.NET and a few weeks at Ruby on Rails. While SQL data stores are EASY, user interface is HARD -- but worth it when your application still functions through OS upgrades. You can always use an older browser if the latest version breaks something.
I'd recommend you consider either of those, depending on how much funds you have available to implement the project--Rails being the cheaper of the two. Then, ANY system with a web browser can access the data, and you can fix interface pages on the fly as needed rather than taking the whole system down a few minutes for a single, simple update. Those skills might be more marketable in the future.
I will only say one thing.. Watch the "actual" cost of your decision.. Most proprietary database systems are Windows only.. or sometimes Mac/Windows only.
This means that along with paying quite a bit of money for the database system, you must also pay a good amount of money on a Server operating system to run it...
Also, compare the database system with current open source solutions. Is it really worth it? After moving from Microsoft Sql Server(which has a free edition, but anyway) to PostgreSQL I was blew away that people pay so much for SQL Server.. I mean, Postgres to me is a lot more clean, and most of it works exactly how you'd expect(unlike in certain SQL server syntaxes) and it has more features built into it(programming stored procs in Ruby anyone?)
So basically, compared the proprietary with the open source software and decide upon which one to take by total pricing(including OS) and feature set..
Pro of zeroing in on any DB: it's got good non-portable features that help you get things done
Con of zeroing in on any DB: sometimes a different DB is appropriate (for example running your tests with in-memory SQLite instances), but that option is now closed
Con of a proprietary commercial DB: if you need many instances, licensing costs can kill you
Consider the following questions:
How easy (or difficult) is it to make changes in maintenance? Applications are likely to spend far more time in maintenance than they do in development, so if changes are hard, long-term pain is guaranteed.
What is the quality of support? A system that is well-documented, proprietary or otherwise, is going to be easier to work with.
How large (or small) is the user community? Systems with larger user communities mean more people to ask for assistance if and when things go wrong.
How robust are the import/export capabilities of this proprietary database system?
I found the last point particularly useful at my first full-time job. Our client was using CA-Ingres, and no one at the company knew it well enough to write queries to validate the data. So I came up with the idea of exporting the data from Ingres and importing it into MS SQL Server (which I knew from a brief stint at Sybase Professional Services) so we could write our validation queries there. If it had been really hard to export data from Ingres, my idea wouldn't have been an option at all.
From 4D's webpage, I gather that we are looking at a complete development+deployment environment, not a standalone database as such. So the alternatives you could be looking at include stuff like django, ruby-on-rails, hibernate and others. The real question, of course, is if the proprietary system can save you enough money doing the product lifetime to justify the costs of the product. And that would depend on the type of human resources you have available.
4D is a good option for vertial applications. I have worked for a company which used 4D to build a medical records and billing application for general practitioners and specialists. The rapid design and deployment features of 4D enabled the application to quickly move with market desires and legislated changes to medical record storage.The environment itself was not cutting edge, but it was integrated, cross platform and very productive.
If you are entering a market with high vendor lock-in and a high barrier to entry, then I think proprietory integrated development environments are a good option.
At various points in my career, I've used and gotten very good at FileMaker Pro, FoxPro, 4D, and a few other commercial products. Now I mainly use PHP/MySQL, and haven't used the latest versions of any of the products.
I've always liked FileMaker because most people who can use a computer can pick up FileMaker and design their own systems. They don't have to know programming or database design. But, you can "program" FileMaker, put a web front end on it, or do other more sophisticated setups if you need to. Many times I was "handed" a system created in FileMaker by a non-technical person that needed to be made into a full fledged data management system. The good part was that all the "specs" and data flow were already designed into a system. The prototype was already created!
4D and FoxPro I always found required a certain amount of extra programming and/or database knowledge to really do anything with. 4D & FileMaker are really complete self-contained systems, not just database systems. Although they all have the ability to hook into other backend databases systems (i.e. MySQL, Oracle), that is not their strong point.
On the downside, doing more complex, dynamic systems can be difficult in 4D and Filemaker due to everything being tightly coupled. Because of their cost, you really would want to create multiple systems with them. Which means you need to really "buy into them" to get your money's worth.
The key concept is always adherence to standards: if you plan to use 4D's custom and / or special designed functions (but the discussion could be far more general, and cover any other free or commercial tool in the wild), well, just use it and take your advantage.
Not surprisingly, that's why huge DB systems like Oracle or IBM's DB2 in the past were wide accepted for specific business areas, as commercial transactions, for instance.
The other main reason to adopt a very closed solution is the legacy support. One of the products you cited (Pervasive SQL) acted as a no-effort port for BTrieve-based applications in late 90s, and it gained popularity thanks to the huge BTrieve community all over the planet.
Finally, last but not least, you should evaluate the TCO (Total Cost of Ownership) not only in terms of license price (single seat, network environment, site licenses and so on), but also for what concerns tech support, updates and availability for your platform. Many business units I know have been obliged to change their base OS for DB related problems.
Tip: add a bonus for custom solution that are proven or supported for usage in virtualized environments, if you aren't in seek for extreme performances. It will save more than a head ache for your DB manager.
In all other cases, rely on opensource/freesoftware DBs. MySql and Postgres for big projects, SQLite for single app persistence layer. Fairly standard and very good (community) support. Good value for no price.
I don't have any experiences with the proprietary database products you listed: 4D, Pervasive, FilemakerPro.
I'd be interested in knowing what those products offer that make them more attractive to you than the open source alternatives, you listed: MySQL and PostgreSQL.
I'd be interested in what makes those more attractive to you than the much more popular proprietary alternatives: Oracle, SQL Server, DB2, etc.
Without you providing more specifics, it's hard to advise you.
I personally feel safer using a widely used open source solution than a narrowly used closed source solution. The more widely used, the more battle-tested it's likely to be. The more open, the more control over my own destiny I have in case I do encounter some bug.
I have reported bugs to open source projects and gotten a quick fix. I have reported bugs to companies that make for-profit proprietary software and have gotten nothing.

what public service project would you create

if you had
4 software developers
any open source software
server hardware
internet connection for hosting
100 person days in which to do it?
How about a site equivalent to Rent-a-Coder but for non-profits to solicit volunteer or low-cost developers for public service projects (i.e. make your question easy for the next guy in an equivalent situation). Given the current economic troubles, there are likely to be both a lot of unemployed developers and a lot of troubled non-profits (and a lot of demand for the various kinds of help those non-profits provide). Let's put them together.
Add a point system like StackOverflow so you can earn points by helping out non-profits with their web applications or whatever. Then go get some corporate sponsorship so that you can turn your points into credits at Amazon.com or some such.
Something to replace diebold software?
Duke Nukem Forever? :P

Adopting Open Source Software in an organization [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
What are the pros and cons of adopting Open Source software for an organisation? Is there anybody out there who has done this and how well has it been working out with some examples of the softwares they adopted and how it has been in use?
Usually contributions come because people do it as a hobby, then how can we make sure that there will be continued support for it? IMHO, in case of proprietary software there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable. Correct me if I am wrong. What are the arguments I might expect from a Manager who might oppose the suggestion to use Open Source softwares?
The term "Open Source" only describes a licensing model. Strictly speaking, the only pro that you are guaranteed to have are the freedoms given by the license, and there are no cons that you are guaranteed to have.
There are many Open Source products that are also commercial, created, maintained, and supported by a company for a profit. There are also many Open Source products that are maintained by volunteers but also supported commercially. For example, if you buy Red Hat Enterprise Linux, then Red Hat will support you on all of the products that come with it, even the ones that are maintained by volunteers.
As for how to be sure that there will be continued support, you can't. Not with Open Source, not with proprietary software, not with anything. With Open Source, if the community is large enough, you can be reasonably confident that the community will continue to maintain it (maybe under a new name) even if the current maintainers abandon it, and you have the option of maintaining it yourself or hiring someone else to do it. Maintaining it yourself may not be an attractive option, but it can be a life saver in a pinch.
With proprietary software, if the author decides to stop maintaining it, you are just plain out of luck. Consider, for example, the thousands of users of Visual Basic 6.
The main pro of Open Source software is illustrated by your comment:
[In the] case of proprietary software, there is an incentive for the organisation (money), and they will keep hiring people to keep it under development as long as the software is profitable.
The trouble is that if it ceases to be profitable (for example, because the code is so stable that people buy it and continue using it without needing upgrades), then the users of that software can be stranded with their nice stable product running on increasingly ancient machines until, one day, the machines crash, or must be upgraded to a new version of the operating system so that they can run some other system, but because the proprietary software is no longer maintained, you have to give up on the application. Indeed, it is not unheard of for companies that sell proprietary software to go out of business. And, if you did not ensure that there was a code escrow account for the software to protect you against the possibility of the vendor going out of business, then you are stuck.
If the code was Open Source and you were sensible (you obtained the source when you obtained the product), then you can take the old product and port it to the new system. How hard that will be depends on the nature and quality of the code - but it is possible. If the software was proprietary, you may never have the option.
The question is: what do you mean with "adopting open-source software". if you are planning to radically exchange every piece of closed-source software (CSS) with Open-Source Software (OSS), you will fail horribly.
I can guarantee you that your organisation is already using OSS in key parts of it's IT-infrastructure.
In my point of view, you only need to formalize how OSS may enter the company and if (and in which form) the company contributes back to OSS. Most companies require a support contract for mission-critical software and mandate that OSS needs to be bought through vendors which provide support.
In many cases, contributing back to OSS-projects is explicitly forbidden and only allowed after the CTO/CIO signs of on a specific contribution.
Simply make sure that your policies are flexible enough to allow what the IT-department currently runs.
It doesn't matter what Manager opposing Open Source is saying.
You have to know well Open Source product you are about to use.
You have to be sure that it right solution for company.
You have to be confident that you can find people on market who know or can learn to use that product.
You have to know TCO for that product.
Then you can argue with manager and give him good reasons how company can benefit from Open Source.
Keep in mind that cheapest solution is not best solution. Companies need to earn money not to save money.
Depends on the situation, but usually, for a, internal, non-critical, no need to secure system, like most of what is done in enterprise, open source is like Halloween and you don't really need to care as long as you follow enterprise policy.
For the other big, important, need to be secured projects, its really simple. You need to have a part in the projects you use and have an internal repository hosting the project (so you have an internal branch that is kept in sync with the external branch). The thing is that those apps are the ones that take a shit long time to make and are supported for thousands of years. The teams tends to change a lot and there's a lot of people involved. Somebody needs and can be assigned to repository/build management.
Now if its only about the manager, then its just about communication and argumentation. Usually they are scared about support because its the long term cost. They tend to like to hear about best practices, well tell them that's what the big companies do (and examples) and that they also tend to participate in the projects and other times they even or its possible to find support for it.
Also, any contractor will be glad to give support of an OSS. Who would say no to money and the ability to develop an OSS.