Engaging with the OSS Community 83
s390 writes "Olliance has the second of its Open Source articles up at the Inquirer. It's called "Engaging with the Open Source Community (Part Two)", and it explains the different levels of involvement that companies can have with Open Source. More education for managers, and an outline of a corporate process for approaching adoption and deployment of Linux and other Open Source software."
A company that OI am aquainted with... (Score:5, Interesting)
And yet they still don't use OSS, despite the fact that it would offer them huge cost savings, less problems with obsolescence, a decent code base for internal development and many other advantages. It's really, massivly bizarre why why don't see what they could gain.
Perhaps they have been locked in a cuboard for the last 10 years and don't realise it exists?
Mind you, this _is_ British industry - a culture exists where if there had been a practice of lopping off the foot of every new hire for the last 20 years it would carry on forever, because 'that's the way we have always done things'.
Zzzzzz... (Score:5, Interesting)
Maybe i'm a little naive about the needs of enterprise users (a term that seems to be more and more misused as a selling point), but this article makes things seem a lot more complex than they need to be. Engaging the open-source community? Five levels of involvement? Gimme a break.
A business that's considering moving into widespread use of open-source software has a lot to consider, that much is obvious. However, the article strikes upon the most resonant point simply by mentioning that a company has to consider what suits their business best.
Most of what this article touches upon is simply extraneous, as it's covering basically what one goes through when deciding on *any* software. Budget constraints, long-term cost, difficulty of adoption for the end-user, and so on and so forth.
The community should be taken into consideration as necessary; it's a resource like any other, and your level of participation is dependent upon your needs as a company. Go with a commercial vendor, you get tech support, plus the benefit of community feedback and assistance. Go with a free one, you negate the tech support and interact with the community at large as much as necessary.
Honestly, if you're running a company and need a guidebook on how to engage with a community of developers and users, you need to step back and re-evaluate your tactics. This is mindless cruft for managers without a clue as to how to interact with people. "Deciding to engage"..pff. What are we, the friggin' Borg?
I can't help but be reminded of Fear and Loathing In Las Vegas, where a so-called expert is on stage droning on about the various levels of a dope fiend. You can describe as many "levels" or "points" as you like, but in the end, software is software, a dope fiend is a dope fiend.
Regardless of how you "engage", considerations like your budget and potential risks as a result of a adoption are pretty damned universal. It's not a goddamned 5-step program.
changing the way Enterprises view software (Score:5, Interesting)
I think that as Enterprise IT managers start to wake up to the costs of vendor lock-in for tailored or custom applications, the response will be a demand for greater control.
Total control is obviously Free and Open source.
Code escrow it the next degree of control - think, when the corporate development and support ends, the source is delivered to the Enterprise.
Finally, proprietary code with an extended waranty that provides no-cost fixes for custom or tailored software that fails to perform as advertised is the minimum degree of control that would be required by the Enterprise for it to be considered a capital investment.
I can think of a half-dozen crappy custom product vendors that couldn't survive such a method being adopted by a broad slice of their market, and I think it would make the world a better place.
he dont quite get it (Score:2, Interesting)
public domain != OpenSource/Free Software
i'm worry about people dont getting this.
Re:A company that OI am aquainted with... (Score:3, Interesting)
Would this company replace its system only because it's proprietary and possibly spent more money? I think the answer depends on how much "more money" is.
In my homecity, the local library still uses an old server with dumb terminals, and I think the whole administrative systems is based in it, the very system that was bought 20 years ago. Here, in the 3rd world, would be a shame to spend money replacing a system that works fine just because it`s proprietary.
Other ways (Score:5, Interesting)
We found an open source app that did nearly what we needed, so we contracted the developer to add features for us (into the main open source version).
Obviously this works best when there is one person or a company behind a project, and also when the features you need are in line with the overall direction the developer is willing to take the project.
I envision a system where this could be expanded, where end users would bid competitively on which features to be added or bugs to be fixed. I've seen some attempts at realizing this sort of system, but none have caught on in a big way.
This could even work in a micropayment world, since a central site could take a block donation of a minimum of say $20-50 and then you could split that up as small as a dollar at a time between different projects, features, and bugs. The developers would get paid in minimum sized chunks too, so on both sides, the traditional barriers to micropayments (high transaction costs) are reduced.
Think of it kinda like a bug bounty that some projects do before a major release, but instead of being initiated by the developers, it would be initiated by the users.
An economy like this of development work ensures that the bugs that are most important get fixed, and the features that people want get added too.
Re:More Education For Managers (Score:4, Interesting)
Of course, different companies will choose to be involved to lesser or greater degrees. Most (more than 90%) will be users primarily, rather than getting involved. Of the relative few that do contribute, most of those will just submit bug reports and apply patches. The few that do get more involved will likely be in niche businesses where their cost savings from using open platforms are greater than added customization costs: a few percent at most.
But that doesn't mean that a few won't actively contribute, where their costs of doing so will be less than continuing to pay high annual license fees for commercial software.
Collaborative competition won't be adopted in large companies with major R&D efforts, as you say. But small companies in vertical industries can benefit by pooling their efforts, and it can be expected that some will try.