As much as 95 percent of the world's software is written for internal, enterprise use, rather than by vendors for sale, a point famously made by Eric Raymond in The Cathedral and the Bazaar. Much of this software, in turn, has no proprietary value for the enterprises that develop it. So why isn't the world deluged with …
Open an closed
"open source is hard"
No, source is hard. Closed source suffers many of the same leadership problems you describe, it's just that no-one will admit it. Unless the Button Monkey has the right drive and sense of reward you rarely get great software. I'm not saying they're underpaid - a sense of reward comes in many forms.
Perhaps the entire IT operating model is flawed?
Internal code usually has good leadership - you usually have a project manager and programmers working on the code, it follows the internal development guidelines, it is documented and above all supportable.
If not, your IT department or internal development department (espeically the management) need a kick in the rear!
Re: good leadership.
Not at the last place I worked.
Project Manager - well, at least on the org chart, functionally....
programmers - spin the roulette wheel for quality, then spin again for quantity.
internal guidelines - "our coders following industry accepted best practices" with no further details.
above all supportable - he-he, ho-ho, ha-ha, he-he, ho-ho, ha-ha, no, he-he, ha-ha, please, he-he, ha-ha, stop! he-he, ha-ha, You're he-he, ha-ha, ho-ho, killing, ha-ha, ho-ho, he-he me!
IT ... need a kick in the rear!
Absolutely. Computers first entered businesses through the accounting department. To this day, IT reports to the CFO, who is often not an enlightened or creative person, and who's favorite word is "No." So many IT orgs play whack-a-mole and slap anyone who shows the slightest spark of initiative. Is it any wonder they then get less-than-stellar results from their crewe?
@A. Coward -- Re: 'Is it any wonder they then get less-than-stellar results'
Precisely correct. It's a never-ending battle with accounts/CFOs and executive management who've little to no understanding of the issues but who've always a razor poised to cut the IT budget at the slightest excuse. Thus, more often than not, internally-generated code simply ends up as a means to an end.
The result is that programmers resent that they end up having to code something more akin to a Heath Robinson/Rube Goldberg contraption than that expected in a properly managed project.
Whilst their coding may be ok for what it is, what's there is hardly adequate to do the job in hand let alone be let loose as a general purpose app.
Project Manager - well, at least on the org chart, functionally....
That sounds frigteningly familliar.
"Open source is hard, precisely because it requires significant human investment"
Oh. I see. And closed source requires no human investment?
That would explain why most closed source is crap, then, right?
Human investment got to do with it?
There is a lot of work goes into internal applications, I know, I've written bespoke applications, either for my company or as a contractor for other companies for 20 years.
The teams are usually professional and the code is well documented.
We are not talking about closed source commercial here, we are talking about bespoke software, written within an organisation; a very different kettle of fish.
The problem is getting that code outside the firewall, as the article discussed.
I think you have misunderstood the article.
Or put another way...
Hey I'm famous, well sort of anyway.
I used to help run a famous Linux distro until we screwed it up really badly and all abandoned it.
But hey, I'm famous and I'm a leader and unlike Miguel and his buddy buddy Microsoft thing I'm responsible.
You can give me your code, honestly.
Look, all you need is a leader, like me.
My article tells you where you are, and who you need to help you progress. Me, I mean a leader.
And not Miguel.
Possibly, but there's a slight hint of continuing need for total corporate control over the assumptions of project leadership and community. The point about Freeing software is that it becomes Free, or at least, it was with the enterprise code we considered for this option. It could be a little over-ambitious of a corporate, even a Fortune 500 company, to expect the world to beat a path to its ftp servers just because it releases some code, which it thinks is up to snuff. Chances are, the code will be released and it'll take some time before any of the scary stuff happens, if at all.
not hard -- easy
It's extremely easy to release code under a Free licence as long as you have written it yourself. Just check the copyright notices and add a reference to your chosen license in the source files, then publish them on a web site. Job done. If your code is additions or modifications to an existing project it is nice and polite to notify upstream so that they have the opportunity of merging your code.
The code is now Free and you have no further obligation to anyone.
This article is a load of FUD concerned with corporate types trying to manipulate a "community" to their own ends in the manner of Oracle etc. It is NOT about releasing code under a Free licence. Terms like "open" and "permissive" are just PHB marketing babble, intended to mean little and create confusion.
If you write something at work you _cannot_ just release it as open source on your own. Why? Because the company who paid you while you were writing the code for it at work is who owns the copyright, _not_ you.
You are in fact infridging on your employer's copyright if you do release it and are then liable under copyright law. So no, he's not talking FUD, he's talking 'real world' and 'having a job'.
On topic, the points in the article are very accurate and have been in the situation where you want to release some code you wrote at work as open source but can't either due to legal or de-coupling issues. Legal because you need to get it signed off by someone and no one wants to take responsibility for releasing proprietary company code, no matter what the purpose and de-coupling because more often than not the code you want to release relies on some other library which either cannot or should not be released.
Sadly, the easiest way to open source that kind of work is to recreate it at home on your own time without having the original source code at hand.
Re: not hard -- easy
Actually, "permissive" is a useful term because it describes a subset of Free Software licences. But anyway, this stuff should be easy but for a lot of developers it isn't. Why? Because developers, software engineers, computer scientists are not taught about things like software licences, or at least they weren't. As a result, the discipline is too focused on the process of implementing solutions and assessing those solutions from a purely technical perspective without considering the origins and licences of the different parts.
Developers are taught about things like modularity, re-use, integration with "Does it work?" and "Is that effective?" as the only criteria for assessment. Consequently, a lot of software engineers probably don't realise that they're doing something with an impact on the potential for redistribution if they find some "nice code" somewhere that they then incorporate into a project. If the project is closed or internal, they will probably get away with it in most cases, but the bar is higher for projects with the source code laid bare. Either way, you can't delegate this stuff to the legal department after the fact - how are they supposed to know if something bad was done? - and to do so is commercially irresponsible regardless of whether a project is open or closed.
Some people will argue that Free Software (or open source) projects add needless overhead, but this is nonsense. Such projects actually demand a degree of necessary discipline that is lacking in huge areas of the software development world. That said, such discipline is not rocket science and proper practitioners should aspire to, and be readily able to, acquire it without too much effort.
re: Not quite
Sorry for not making myself clear. The article seemed to be written with respect to the corporate point of view , not the employees'. My comment was meant to be interpreted from the same standpoint. I should have written
"as long as you have written or commissioned it yourself."
I am fortunate to work for a Free Software company and all of our code is GPL or AGPL with copyright assigned jointly to the company and actual authors.
The article referred to a "senior IT executive", who presumably had the authority to make a decision. Third party code isn't yours and you don't have to worry too much about it. Just obey the copyright owner's licence. After all plenty of GPL software is deployed on Microsoft and Solaris platforms.
re: Re: not hard -- easy
>> Actually, "permissive" is a useful term because it describes a subset of Free Software licences
I think that you have got that wrong. ASL, MIT, and BSD licences are all "OSI approved" and generally termed "permissive", but they are not Free Software licences. These "permissive" licences are designed to favour re-distributors at the expense of the authors and end-users.
I am waiting for some details to emerge about the money behind the current anti-GPL campaign.
@vagabondo, stop drinking the FSF koolaid
BSD license is not a free software license? Really?
Actually, most of the time software is released under a permissive license it is precisely for the opposite reason - permissive licenses are the only licenses that allow for all computer users to freely use and benefit from common code. This leads to true code sharing and well implemented standards, for instance BSD sockets, OpenSSL, OpenSSH, BIND, pf, et al. I think you would agree that it's pretty handy all the OS in the world use the same sockets library.
Your beloved GPL licenses only provide that freedom provided that you share any changes you make to that software, which means that they are not used as the basis of products by companies who actually wish to turn a profit.
As a concrete example of this, the server appliances made by Cisco IronPort (email filtering, etc) run a closed source OS based around FreeBSD.
Now, to a rabid RMS lover like yourself, all you see from this is that the FreeBSD project never sees all the improvements Cisco make to the OS.
What you miss is all of the benefits FreeBSD gets from being used this way, Cisco employ a lot of FreeBSD core committers, and the non-core bits of AsyncOS do get pushed back to HEAD, since it is better/easier to maintain for Cisco, and doesn't enable a competitor to get a leg up.
Disclaimer: I was paid to write this by the Secret Anti-FSF Project, which was paid for by Microsoft. Well, you're clearly going to think it anyway.
You can't post any code without your company's permission.
It's not your code, it's your company's code! Any intellectual property you create using company time or company equipment is the company's! You can't open source it and expect to keep your job. You might even get sued by your ex-employer. Even if you wrote it at home, the code can't be remotely related to anything you do at work.
Re: @vagabondo, stop drinking the FSF koolaid
"BSD license is not a free software license? Really? [...] Now, to a rabid RMS lover like yourself"
Oh dear! According to the FSF, many permissive licences are Free Software licences, just not copyleft ones. The FSF even recommends the Apache Software License 2.0 for some things. So this has nothing to do with RMS or the FSF - it's merely a misunderstanding by the commenter in question compounded by your own misunderstandings of who has said what.
"What you miss is all of the benefits FreeBSD gets from being used this way, Cisco employ a lot of FreeBSD core committers, and the non-core bits of AsyncOS do get pushed back to HEAD, since it is better/easier to maintain for Cisco, and doesn't enable a competitor to get a leg up."
Yes, but Cisco need not employ committers, nor do they need to share any source code. If Cisco felt that they could outrun FreeBSD in any particular direction, they would be free to do so. Moreover, IronPort was originally a separate company, so I imagine that any choice of FreeBSD is a legacy from that particular business just as the use of GPL-licensed software was the basis of Linksys' strategy before they too became part of Cisco.
>> BSD license is not a free software license?
Yes, really; providing you spell "Free Software" capitalized as both myself and AC-12:06 did. The current BSD licences are compatible with FS licences. The point about the ASL is that it permits code to be imported into a FS project and relicensed, hence becoming "Free" in the Free Software sense. The point of the BSD (and Apache) licences is that they now permit companies (such as Cisco, and Apple) to create proprietary derivatives and be selective about what, if any, code they choose to share. I, personally, think that this is appropriate for code that has been produced at the taxpayers expense. Some of my code was released under an original BSD style licence (with attribution to my university employer), but that was before the GNU project or the three clause BSD existed.
No need to be rabid, or a fanboie -- just stumbling towards accuracy and truth.
I don't think the original article was referring to some corporate peon wanting to chuck his code on to the Internets which is what you are talking about.
He is talking about organisations who have their own, in-house developed code and that same organisation wanting to open source it.
I assumed the previous poster was speaking as the company
not as an individual within it.
Abandoning (freed) code is easy, nurturing aint
Yes it is easy to throw some code up on one of the big sites and abandon it. It's like putting your old furniture out on the verge for a special rubbish collection - some people will fossick through it and get things they can recycle.
Putting code out to build and nurture a community is harder in open source than it is within many organisations because open source communities typically demand a messy open management style.
I've disagreed with a lot of this author's articles but this one makes a lot of sense.
BTW I've developed a lot of code in many oranisations in nearly 30 years of programming, including contributing to mid-size open source projects and releasing much of my own work as such. Even products which people were willing to pay for can fail to attract contributors and regular use.
There's also the "invisible success" phenomenon where you release something, people pick it up and use it but never become "community members". That happened to me with my XML layer expatpp - I didn't know Steam used it until I saw my name in a book and Dr Dobbs article! (Hey Valve, if you're listening, a free account would be something I could finally impress my teenage son with!).
"You are in fact infridging on your employer's copyright..."
That's a chilling thought.
Standing naked in the gym
Most of the closed source code is only ever (re)viewed by people in your close peer group and tends to never reach the high standards required by 'everybody'. Its often rushed and 'does the job' and can exist within its limited role for eternity without any major flaws coming to light.
Putting YOUR code into the public view is stripping your soul naked - I've made major cockups at work and shrugged them off but the embarrassment of having a few thousand lines of hard grafted code being replaced by 10 lines by someone who knew a different approach is enlightening to say the least. In a company I've had my 10 lines rejected to keep someone higher up the food chain in work and in FLOSS I've had the piss taken out of me, I've learned and the code was a damn site leaner.
Open Source can show that, after 25 years in the job and generally knowing more than anyone I've worked with I still know jack.
Doctors have it right: they Practice medicine. We Practice software engineering. Closed Source is Playing - you might be able to get away with it and get paid very well for it but the end results keep several large AV companies happy and you and others more ignorant than should be.
Even if your write closed source code a trawl through floss code will be a learning experience.
Re: Standing naked in the gym
I don't see this. Most of the open source software I've seen is poorly documented, some has terrible design at the function level; the lack of any overview description makes it impossible to tell if the overall architecture is any good - or even correct.
Usually it's just a load of source files and a make file.
I'm not saying it's all like this, some bits may be better, with tribes of enthusiastic developers and reviewers who keep the code clean, tidy and well documented.
It seems to me that it's no better - or worse - than other code.
the penultimate man-machine interface
Where I used to work, one program, through which the entire product line funneled, had had a bug that required manual intervention. We referred to this intervention as "GOSUB KEITH." Every time the job ran, it would abort after it reached a certain point. Starting it up under the debugger and stepping through some instructions would allow Keith to allow the program to run to completion in the context of the debugger.
Not an elegant solution, but a solution none-the-less.
Help is available!
If your project has sufficient merit to attract interest, help is available with the legal and community issues of open-sourcing it. See http://incubator.apache.org/
Missing the point
As 95% of the worlds software is written for internal enterprise use, most has little to no value outside of that enterprise, or worse would give competitors understanding of the internal processes of that enterprise.
So really the question is why would you go to the additional effort, no matter how trivial that may be, to open source something that has no value to anyone else or possibly may even be detrimental to your enterprise. Answer you wouldn't.
Pretty simple really.
'unlock the treasure trove of isolated, enterprise code'
Possibly the funniest thing I've ever read.
A whole load of words around no problem
Anyone wants to make a software project available to the public: do it.
Dedicate a website to it. Fill the front page with legal disclaimers and sleep easy.
If nobody uses it, well, that's their choice. Giving does not oblige others to receive.
If, on the other hand, it does get used, that's nice.
If it gets popular, wow, it's "community" time. Successful communities happen and grow: they do not get artificially created.
What's "hard" about that?
what's hard about it?
one URL should serve to illustrate what's hard about showing your working to all and sundry.
Hang on just a second there, hoss....
Corporations develop internal software to gain a business advantage over other corporations. They often spend very large sums of money to do this, having first reasoned that this expenditure will save them significantly more than they spend.
Why in the name of all that is holy would they then give away this commercial advantage to other corporations, a good number of whom will be competing either directly or indirectly for the same business? Makes no sense at all, and is, I suspect, a mere pipe dream of open source evangelists.
Can somebody explain to me, how gplv3'ing my code, which has absolutely no warranty. then putting a public read-only git repo on my server, is opening me up to legal issues???
I mean, if the company gets the green light on the code it's releasing (i.e. you legally own all the copyrights) then how can I legally be liable for anything, every source code file contains THERE IS NO WARRANTY....
so I don't get it.....
also, leadership? why do people complicate things so much, just put it online, don't do anything, update it with new code periodically, don't do anything more, people want leadership? do it yourself....why do people feel the need to create a leadership in the first place? leadership of what??
Confused me as well
The licenses I see go beyond "no warranty" and actually say, essentially, "hey if it blows up - don't come knocking on my door - use at your own risk".
Is there any legal precedent where, in spite of such a caveat, a suit has been successful (or even made in the first place)??
Open Source is easy, successful open source is not
The title is really wrong.
As you say, making a project open source is easy enough. Just upload to sourceforge or whatever and you're done.
However, making a **successful** open source project needs the investment of time and effort to provide community leadership, project direction etc. That's a lot of work that is hard to justify if there is no corporate benefit.
What did Joe do last week? He spent two days merging in changes to make the software work properly for Company Y.
Without this nurturing, an OS project soon becomes abandonware.
But you *can* offer a warranty:
"We warrant that the Software will, if Compiled successfully (with no error messages) and exactly as per the enclosed Build Instructions, in its unmodified form, on a suitable Device which is functioning properly throughout the process, do exactly what the Source Code says it should do when it is Run."
Good luck claiming against that, though.
Or could it be
that closed source will never be opened because of the amount of code lifted from open source projects to build the closed source stuff...............
I call bull
I hate it when famous people write such lies. Open source is not any harder than any other type of software development and the reasons why corporations don't share their code has nothing to do with avoiding lawsuits. I worked for a VERY large company for over 5 years and we gave away almost everything. In each package though we had a legal disclaimer that protected us. Not once were we sued. Most other enterprises were just happy to have a jump start on their own development efforts and appreciated the generosity.
The real reason why corporations don't share even non-commercial code is because everyone believes their code is the be shiz and gives their company a competitive advantage. It's greed, not 'a desire but no means', Don't lie, Matt.
Open source is a great hobby, you get to work with like minded people on a project which really interests you, if you are lucky you see the work progress faster because someone else picks up the bits you aren't so interested in, and if you are really lucky you get some kudos at the end.
Open source can also be a great business model, particularly if there is a large user base for a low value product in a crowded market.
But why would an enterprise open source its proprietary business software? The main effect of that would be to help their competitors. They might as well share their sales leads or send over their best managers to sort out the competitors business processes.
You don't need to look for reasons why this isn't happening.
Perfect Lodes ..... Giving Nodes. Equalism in What you Give is What you Get .
"Few legal departments want the potential risk associated with releasing code that is generally a) not directly driving their business and b) potential lawsuit bait.
It's just not worth it." ..... Matt Asay
Run a Virtual Proxy Server of XSSXXXX Code Delivers Zero Virtual Reality Control Risk in Parallel Illicit and Illiterate Legislative Systems. ........ is Heavy Duty Pure Crude ...... and Crazy Diamond Black Gold Ore.
It is of course the Virtual Reality of Everything which IT Controls which so Intrigues One to Ponder and have a Dander and a Wonder on what can easily be ..... and therefore is a Perfect Heavenly Place in Space with CyberInteAIgent Command and Control Abilities for Remote Access to Vital Component Leverage via Intellectual Property Placement of Alternative Media Presentation of News and Views which Media needs to Survive and ReInvent and ReInvigorate itself in the Future..... Now.
Is there a difference between televised fiction and televised fact. And if there is, is it because of a lack of easy to follow script to a profitable conclusion, ergo must all televised programs have an already made script, which they follow religiously?
Your concept on open source within the firewall is a bit unclear. Promoting re-use of good stuff around the broader enterprise to save money and avoid fragmentation = a good thing. This approach used to be called "reuse" and is largely orthogonal to private/oss licensing. e.g. reuse CICS death to TPF, reuse Apache web server death to IIS.
Infamously enterprise reuse (as opposed to more local kinds) was declared bunk by an old BT CTO which may well have been true for his time and place. It is certainly difficult to achieve across P&L areas in big corporates and away from infrastructure topics. Creating sustainable (5-10yr+) models for your own code - maintaining traction on adoption/upgrade and allowing technical renewal is difficult mostly because of community size/people and business project governance issues. Licensing approach doesn't feel like the primary issue within the firewall.
What in your view - does recasting the local "common code" as open source within the firewall add that drives business area / project adoption or helps sustainability ?
Most software is closed source because most software is buggy crap and companies don't want outsiders to know it. There is a realistic fear that the security bugs that the company's programmers know exist but haven't closed down yet will be found quicker if the code is released.
Open isn't hard, software is.
Most software is not reusable
There may be snippets that are reusable but whole projects are not. Often software is not reusable even within an organization - different software for different business requirements requires different data and different performance characteristics. The idea of a common shared data dictionary usually fails: the number of people required to agree on it, and the level of compatibility between different applications, causes serious inertia to project changes and functional compromises. It usually causes departments to do an end-run around the IT department.
Fred Brooks (Mythical Man-Month) said it takes 3 times as much effort to produce a programming system - with interfaces between components and integration - as it does to produce a program, and 3 times as much effort to produce a product compared to a program. The two axes are independent, a 'programming system product' costs 9 times as much. To be of use to more than one company or user, any release would have to be a programming system product. If released as simply a program, any company adopting would have to adapt it as a PSP - which will cost them 8 times as much as writing their requirement from scratch. It's simply not worth doing.
The additional costs also apply during the maintenance and feature development phases - you have to ensure that every bugfix doesn't break the test scenarios for other customers or cause regressions for scenarios that you don't even own, or might never see. (Open source is frequently weak on testing: unit, integration and scenario.)
This is leaving aside fundamental problems with suggesting that competitors co-operate on line-of-business applications. In some cases the companies see the software as providing a competitive advantage.
I think the best we can hope for is that generic tools and utilities that assist development of larger solutions get released.
If you find that your "only snippets" of your software are reusable, then You're Doing It Wrong.
Either you have fundamentally misunderstood what can and should be abstracted out into reusable modules / libraries / whatever they're called in your Language of Choice, or one side of your interfaces lack consistency.
Of course, keeping the Source Code closed allows you to disguise this.
so my question is
Would it not make sense to start enterprise coding as open source from the ground up?
Admittedly it would not solve the immediate problem of existing code remaining closed, but take a decade or two down the line...
The benefits to any given organisation would be tremendous, as the collaborative model is already there, designed to quickly on-board and off-board developers and so forth.
Your right in principle... but the legal system IS an issue
What we're seeing is old-school (i.e. pre-1776 and Adam Smith) mercantilist thinking-- competition as a zero-sum game. This is the thinking that cost England its American colonies by trying to restrict trade in the name of keeping the resources on the other side of the Pond to itself. If a significant number of enterprises adopted this model, everyone would benefit as there would be a Darwinian process where the good bits multiply and the bad bits die. Who knows, you might even see enterprises agreeing to save money on software infrastructure by working together so they can get on with selling oil/cars/toothbrushes/whatever. Then competition would happen on the basis of who has the better product not on who has the least buggy code.
Unfortunately, as long as the patent system remains broken (ironically, the US patent system was originally designed to promote innovation rather than stifle it) and as investors abuse due diligence lawsuits there will be legitimate fears that will prevent open sourcing of code.
Sound like an idealist pipe dream? So was free trade in 1776.
If people are giving the fruit away, the recipients can't expect to have it picked, washed, sorted and fed to them. It should be sufficient to publish, with a disclaimer that any code may need tweaking to match the problem at hand.
You're right but good luck in front of the judge....
And the problem with disparate organisations constantly re-inventing the wheel for no good reason is?? Keeps us lot in work!!
I open sourced a little app about 5 years ago, saying "I'm done with it, here's all the source, released to the public domain, no license terms, do as thou wilt. Here are clear instructions for the (free) tools that you need to build it, and here are step-by-step build instructions. Good luck."
To this day, I still get both polite request and bare faced demands to implement features X, Y and Z. As far as I can see, not one of the sponging mongs has taken it upon themselves to pick up the ball and do their own build. You just can't help some people to help themselves.
- Apple's spamtastic iBeacon retail alerts launch with Frisco FAIL
- Submerged Navy submarine successfully launches drone from missile tubes
- Pix Astroboffins spot HOT, YOUNG GIANT where she doesn't belong
- Cache in the Attic El Reg's contraptions confessional no.2: Tablet PC, CRT screen and more
- Developer unleashes bowel-shaking KILLER APP for Google Glass