Strategic Use of Collaborative Development in South Africa – Follow Up

Last week I wrote a blog entry stemming from my experience in South Africa and my impressions about the way the OSS preference policy is being considered. What has come of it is a string of rather pointed comments questioning my intelligence and calling me quite the assortment of names - I though xenophobe was a particular low-point in the comments. Given the comments, it is worth clarifying my thinking and making a few points.

1) I think collaborative development can be extremely beneficial to South Africa. In fact, I think it should be a key aspect to their IT strategy for their eGovernment strategy. I simply don't think that discussion is limited to being about platforms. There is absolutely no reason that the agencies using any platform are precluded from using collaborative development to drive greater value from the existing ICT investments. To the extent that an agency is in the process of considering making new platform investments, then they should be free to look at all options and choose the one that provides best value for money over the long run.

2) I think technology mandates are not good policy in any country. In fact, I remember speaking at George Washington University a few years back and making this same statement. At the time, the Executive Director of the Free Software Foundation and the CTO of Red Hat both expressed support of that comment and that their organization's held the same view. Technology providers want their current and future technologies considered on the merits of the technology and the value those technologies bring to those who choose to consume it. If a government mandates a specific technology and/or class of technologies, they are unnecessarily restricting their own choices. Inevitably statue moves more slowly than technology, and mandates subsequently lead to sub-optimal choices.

3) My comments about the education of developers is a macro point and has absolutely nothing to do with whether those developers are in South Africa or any other country. I have no doubt that there are very talented Linux kernel developers in South Africa. Great - good for them, I think that is awesome. But it still doesn't answer the macro question about the types of projects that will both create high-value solutions and attract local participation leading to the in-country skills development that the policy is seeking to do. While I'm sure there is a subset of folks deeply interested in the core OS functions, there is a reason that a very small percentage of developers work on core OS development. I'd guess this is the same reason that there are relatively few operating systems compared to the literally millions of applications out there. Skills development is a good thing - I'm simply advocating that people look to the possibility that there is far more to collaborative development than OS coding.

4) I made a point in my last post on this subject regarding the opportunities for the creation of local software businesses based on OSS. Many, many governments are eager to see the growth of local software businesses. I am fully supportive of that intent, but don't happen to believe that OSS is necessarily the best model to bring that about. Economic opportunity is bolstered by having something unique. The most successful OSS companies have found a way to "hybridize" their solutions to in some way secure the uniqueness of their work while still tapping into the collaborative development community. Comparing the number of companies that have been commercially successful using that model with the tens of thousands of software providers using other development/commercialization approaches suggests to me that an OSS mandate is not likely to lead to the growth of local commercial software firms.


I was impressed with the people I met in South Africa. But I was also struck by the political realities of a technology mandate vs. the real-world opportunities open to them through a broader approach to collaborative development.

I was deeply involved with a series of projects that demonstrated a wide range of possible approaches to collaborative development (using non-OSS, OSS, and Free Software licensing models; using various approaches to tools, project types, funding models, etc.). Furthermore, I went through dozens of scenarios of thinking about core assets vs. complimentary assets and how OSS dev methodologies could be applied. There is so much more to the conversation than Linux vs. Windows. In fact, given the world of interoperability opportunities today, I'd argue that enterprise-scale environments are far better off thinking about "and" compared to "vs." and really looking at where the value to them from collaborative development is. Commercial implementations of enterprise-class operating systems are not free of cost. So - again, to me, the question is about how collaborative development can be used to extend the value of any platform decision.

Comments (17)
  1. Wesley Parish says:

    I think there’s a point you’ve missed in my comment in the blog entry you are referring to – the existence of a market in the first place.  I’ve come across it being discussed on a number of the Developing world FOSS sites; I haven’t seen it being discussed on this or any other non-FOSS site.

    When you have a large number of (potential and actual) software users who speak a language that isn’t currently economically viable for companies such as Microsoft, how are they to establish said software market if they don’t have a zero-encumbrance way to get the language in use as a supported language on whatever software platform they use?

    This is part of the overall development issue.  And I don’t think Microsoft is at all helpful in this particular issue.  I’m afraid that mandating FOSS is the only workable option – since adding languages is a zero-encumbrance matter with FOSS.  If Microsoft doesn’t like it, it’s not directed specifically at Microsoft; it’s structural and would still exist for IBM, Sun, HP, SGI, you name it.

  2. jasonmatusow says:

    Hi Wesley –

    First, I suggest you check out this link:

    The link takes you to the Microsoft Local Language Program which was started in 2004. The point was to address the exact issue you raise.

    Even without programs like that – I still argue that the "mandate" is not the way to acheive the goal. If the commercial offerings are not vialble for a given country, then they have the choice to work with an alternate solution. Constraining choice is not the right answer in my opinion.

    As for "zero-encumbrance" – I don’t necessarily agree. There are costs to be bourne by putting yourself on a custom path separate from the mainstream. That is not a value judgement on my part, simply a statement of fact. It may be that the costs are more than justified by the outcome, but it is not "zero."



  3. Matt Asay says:

    I apologize, Jason.  I think I may have been the cause of a range of people seeing your post, though I take no blame for them misreading it.  You and I have long discussed this point – should governments advocate for a specific software methodology – and used to agree.  I’ve come to believe that governments are right to bias decisions in favor of open source *when functionality requirements can be met by open-source alternatives."

    But I think there’s strong logic behind your position, all the same.  I just question if the burden of locking oneself into a proprietary solution, even when supported by the mainstream, is something that a government should contemplate.

  4. jasonmatusow says:

    Hi Matt –

    I’ve reread my first post and I should have been far more careful with my tone. I stand by the arguments, but I was just drafting quickly and posted too soon. Let that be a lesson to me.

    As for the point about the mandates – I think they are uniformly bad. Clearly in the case of saftey, or when you get to the concepts of a governments role as the "leviathan" to really whack on some political theory stuff – then mandates have a place. But when the mandate is at the level being discussed I simply think there is no place for it.

    If the OSS technologies are better, and offer better value, then people will chose them. If they are not – then they should have the freedom to choose alternatives. If the commercial providers (aside from the Red Hat-esq commercial) prove value without putting their code under OSS licesning (or free software), then so be it.

    The lock-in argument is bogus, and I’ve covered that ad nauseum. If you choose Red Hat, and build your custom apps to that platform, and create dependencies based on IT staff skills, and user traininng, and app-vendor deployments, and….then you are putting yourself on a specific path that is very painful to switch from (say, to Novell Linux with their Mono platform for example). Red Hat absolutely wants the second sale and will do what they can to keep their customers. "Lock-in" is the popular boogeyman argument that just doesn’t hold up in enterprise computing. Of course, I always find it funny that people using Apple products accuse MS of vendor lock-in, but that’s a different discussion. (As an avowed capatilist, I understand the business choice for getting customers to commit to your platform.)

    Anyway – no worries Matt. I deserve some smacking around now and again. It’s good for me. :-0)


  5. Andre says:

    "There is so much more to the conversation than Linux vs. Windows. In fact, given the world of interoperability opportunities today, I’d argue that enterprise-scale environments are far better off thinking about "and" compared to "vs." and really looking at where the value to them from collaborative development is."

    — Why don’t you preach that realism more to your own company?

    "The lock-in argument is bogus, and I’ve covered that ad nauseum."

    No, it is sound economics. Lock-ins are normal. As a vendor you try to create lock-ins, as a user you try to avoid lock-ins, from a market perspective you try to move towards perfect free competition and thus combat lock-ins. From an ordoliberal perspective governments need to make competition work and be cautious with anything else.

    The lock-in principle similarly applies to the Mac which didn’t even learn the lesson of Open Systems.

  6. jasonmatusow says:

    Andre – MS is far more pragmatic than most in the blogosphere think. Take a look at the great work being done now by MS and Novell on interop between Windows and Linux (virtualization, management, etc.) that is just an example. Listening to customers is always educational and they are all speaking in terms of "and" instead of "vs."

    As for the lock-in, you and I are in agreement that vendors seek to find ways of retaining customers – but that is true for ALL vendors. To the extent that we have been talking about this within MS, there is a natural tension that exists between commerical intent and interoperability. The conclusion we have drawn is that customers must own their data – they must have the freedom of the "when" and "why" of exchanging (or exporting) that data. The vendor is responsibile for providing one or many "how" opportunities for the exchange of that data. Document formats and protocols are at the heart of this discussion. APIs provide opportunities, but documentation of those APIs is arguably more important than the source code for them. Once you get to the source discussion, then you are right at that friction point about commercial opportunity.

    Anyway – My point about the lock-in argument is that it is used as a FUD sound bite with very little thought.

    Thanks for the comment.


  7. Andrew Sayers says:

    On the topic of lock-in in general – surely lock-in is actually bad for a vendor in the long-term, because protecting themselves temporarily from competitive pressure makes them less competitive, and therefore at more risk in the long-term?

    As a case in point, people were locked in to IE after the browser wars, which let Microsoft get away with leaving it at version 6 for several years.  IE6 had become obsolete by the time the playing field levelled out, forcing the IE team now to work their socks off just to catch up with other browsers.

    – Andrew

  8. jasonmatusow says:

    I agree Andrew. Look also at the progession of the Mac over the years from an adoption standpoint from the rest of the industry.

    This is exactly why I’ve been really happy about the interop principles that MS has been talking about. The most common form of vendor control has been about data. Think about SAP or Oracle products for example.

    thx for the comments.


  9. jasonmatusow says:

    I agree Andrew. Look also at the progession of the Mac over the years from an adoption standpoint from the rest of the industry.

    This is exactly why I’ve been really happy about the interop principles that MS has been talking about. The most common form of vendor control has been about data. Think about SAP or Oracle products for example.

    thx for the comments.


  10. jasonmatusow says:

    I agree Andrew. Look also at the progession of the Mac over the years from an adoption standpoint from the rest of the industry.

    This is exactly why I’ve been really happy about the interop principles that MS has been talking about. The most common form of vendor control has been about data. Think about SAP or Oracle products for example.

    thx for the comments.


  11. Anon says:

    Colaborative development is really useful and thanks that your company has started to realize this and created communities such as Codeplex. However, one issue that I have and could

    you please pass it on to the right people to think about it:

    Many projects and most importantly Microsoft code samples are now published under the new Microsoft Public License. I believe that you made a mistake with the Microsoft Public License in making it like the BSD license. The big problem is that the license says that if you use any code licensed under it then you have to publish it under the same MSPL license, meaning that if I want to use some Microsoft sample code or some library function or etc in an open source project that I am working on, it would be impossible if that project is not also published under the MSPL. This is too bad since many open source projects on the Internet are not published under the MSPL and thus you cannot mix code from any of those project with MSPL licensed code. License out there vary from the BSD, to the Mozilla Public License, to the Apache License, to the General Public License. Very little code for the time being is published under the MSPL. I don’t like having all these licenses that are almost, although not quite, identical. I am not against license diversity but there should be a way to move simply from one license to the other if they are compatible. For me there are only 3 types. Reference licenses for only looking at the code, BSD-like licenses and reciprocal licenses. These 3 groups are incompatible. But what about the licenses that fall within a single group and could be made easily compatible? Why should I care if someone uses the BSD or the MPL or the MSPL or the Eclipse License or the Apache License, etc? I know that each license might carry certain benefits than the others, although I have never had the time to figure everything out. What I want as a developer is to use code, most importantly Microsoft sample code, under any license. So, I thnk there should be a 4th group of licenses created that allow you to use your code under any OSI aproved license. In this way I would be able to use sample code from Microsoft when enhansing open source projects whose authors had chosen a different license like the GPL, which cannot be change now. Or you could update the Microsoft Public License to include this provision now that it is still a new license. Include the provision that if you distribute in source code form then it should either under this license (the MSPL) or any OSI aproved license. Currently, Microsoft samples are not accessible to open source developers.

    What do you think? I would like to hear your views on this as I think that it is important.

  12. Wesley Parish says:

    Actually, Jason, the Microsoft site you’ve pointed me to, does prove my point.  I made my mocking "translation" of Microsoft into Maori – with its "translation" of "soft" as wairangi – in 2003.

    I suspect if I had not indulged my sense of humour at Microsoft’s expense, and The Inquirer had not indulged me, Microsoft would still not have realized this.  But Microsoft’s response is still nowhere near as nimble as the FOSS version. You had to point me to it before I was even aware that Microsoft had an offering, whereas Microsoft’s current major competitor is making the marketplace its own.  Eg, is now available in all eleven official South African languages.  

    In those languages, MS Office is not the mainstream.

  13. Mitch 74 says:

    OK, I understand your meaning now, and I’m glad I gave you the benefit of the doubt in your "previous" post.

    Now, there are a few things I don’t agree with on this current post and the following comments:

    – what happens when a government doesn’t mandate a certain type of architecture? Each and every service can choose what it wants. Since the people making choices are more often than not technologically ignorant, they take the most seductive offer; and when there is competition, Microsoft (or others) come in, with a "all our OSes for $3 a year, until the next version". When "next version" comes around, the decision maker isn’t there anymore. I should mention offers like "join ISO P-states, win $1000" as another incentive…

    – currently, Free operating systems fall mainly under 2 categories: POSIX compatibles (GNU/Linux, BSD, OpenSolaris, Minix) and others (BeOS: living dead, ReactOS: alpha state); choosing Free systems and not being completely obtuse means migration to another proprietary system (HP-UX, AIX, Solaris, MacOS X) with little (if at all) conversion costs; scripts, source codes, compilers, VMs etc. have a tendency to be thoroughly tested and swapped around on POSIX systems – where the best at one job goes around. If you start developing for win32, the only way you can keep your investment alive is by staying on Windows.

    On the matter of licenses, several are viral in nature: Microsoft’s free ones are,  and used to be/are restricted to code destined to run on win32 platforms; the GPL is quite locked down, with the watered down LGPL being more flexible; Mozilla’s is more a matter of branding, while BSD and MIT are much more permissive – and subject to shameless pillaging.

    Let’s take this matter another way: if the SA govt’ had mandated, say, "only POSIX systems may be used in our administration", the current result would be the same: a few supported servers driven by Red Hat or Sun or IBM, and a bunch of Linux and BSD systems on users desktops. The day when ReactOS gets stable enough for everyday use, supporting most Windows applications and enforcing stuff Windows supports but Microsoft doesn’t use:

    – ACLs

    – Non-admin accounts instead of UAC

    – No Fisher-Price interface bloat

    – No Rover, nor Clippy (ouch!)

    – A real firewall

    – No system-hidden files like the impossible to flush/destroy IE history file, or Alexa spy

    – Utilities able to not make a mess of NTFS’s POSIX namespace being case discriminant (open an NTFS drive used with NTFS-3G under Linux with Windows Explorer, feel my pain)

    Well, if SA had mandated (any) POSIX platform, it couldn’t migrate; by allowing any F/OS platform, Linux is open yes, but also Minix (microkernel), ReactOS (Win32), BeOS (itself) or anything as of yet not invented – or proposed by Microsoft.

    After all, what prevents Microsoft from proposing a MSPL-covered minimal implementation of the Win32 APIs and NT kernel? Or even, merely sponsor the development of ReactOS, or Wine?

    The way I see it, SA didn’t create a lock-down: it only prevented MS from enforcing one.

  14. Bob Jolliffe says:


    As someone who is very familiar with the South African FOSS policy I still find your original comments on technology mandates confusing:

    "South Africa has taken a most unfortunate position of late – the government has sought to put a political mandate in place for the adoption of open source software. I am against all technology mandates, and this one is no different."

    South Africa has not mandated a technology or a platform or a product.  Indeed it is yourself who seems to be caught up in this Windows vs. Linux caricature of the SA FOSS policy.  Expressing a preference for a licence model has got nothing to do with mandating a technology.  If Microsoft released Windows XP under a FOSS licence it too would be bask in the light of the same policy preference.

    Governments make policy and technology companies make technology.  That’s what we do.  I really don’t think SA is confused about this.  But when technology companies want to wade in and dictate policy it does seem that there is some confusion.

  15. Don says:

    Jason, in my view there are two issues or definitions of *technology mandates* here:

    1) re: interoperability, security  and cost – it is a government’s duty to ensure that all subsections of the government can interoperate freely and efficiently, while permitting efficient maintenance and security of the system as a whole, and at the lowest possible cost to the taxpayers.  In this sense, a *technology mandate* is a necessity to ensure that these goals are met, and is fully justified.

    2) re: open standards – it is a government’s duty to ensure that information is stored and communicated (networked) in a form that is stable, accessible to all subsections, and that can be exchanged globally with other agencies and the public.  In this sense, a technology mandate is fully justified.

    Under both these scenarios, I feel mandating the use of open source makes perfect sense, and will galvanize nearly instant development of open source software to fill all needs and requirements.  In this way a *mandate* to use open source is really not restricting anything.   Vendor lock-in is very real threat, as Microsoft’s 90% market share, constant file-version swapping to maintain the cash flow from users, and legal threats against those who historically have wished to interoperate and share the IT environment with them shows.     Someone has to make a decision in order to change this situation.  Change just does not happen by itself.  Mandating the use of open source is just such a responsible decision, and this decision does not preclude Microsoft from continuing to play a part in government IT.   It just means that Microsoft will have to adapt to a new environment, like all the other open-source vendors, on a level playing field.

  16. Dave S. says:

    One area subject to government mandate is currency. All governments mandate the currency that is recognized in their country. They do so because to do otherwise is to cede vital control.

    Some European countries noted a compatibility problem with their currencies which cost them more than a single standard might. Their solution was to mandate a single mutually controlled currency – not relenquish control to a standard set and managed by others.

    The information infrastructure of a country is becoming as important as currency.

    It makes sense for governments to control the platform their software runs on, letting the applications handle compatibility – much like the relationship between currency and market.


    "Commercial implementations of enterprise-class operating systems are not free of cost."

    This is correct – but the knowledge gained by doing so is invaluable.

Comments are closed.

Skip to main content