Monday Jun 20, 2011

Le Logiciel Libre – Omniprésent dans le secteur public

NOTE : Cet article a servi de base à du contenu publié en juillet 2011 dans le magazine Acteurs Publics.



Créé il y a plusieurs décennies déjà, pour répondre à un besoin de partage de savoir, et de compétences, le Logiciel Libre existe sous plusieurs appellations, à l'origine anglo-saxonnes, dont « Free Software » et « Open Source » sont les plus utilisées. En Anglais, le mot « Free » pouvant signifier à la fois libre et gratuit, cela a créé une certaine confusion qui n'existe pas en Français avec le mot « libre ». Du coup, on voit souvent l’acronyme FOSS ou FLOSS, pour « Free, Libre, Open Source Software » afin d'éliminer l’ambiguïté.


De nos jours, dans le secteur public, le logiciel libre est, depuis, devenu omniprésent. Il répond à plusieurs besoins critiques dont le contrôle des coûts, le choix (de partenaire, de logiciel, de fonctionnalités), la liberté de pouvoir modifier les applications pour les adapter à ses propres besoins, la sécurité provenant du fait que de nombreux développeurs et utilisateurs ont pu contrôler la qualité du code. Un autre aspect très présent dans les logiciels libres et l'adhérence quasi-systématique aux standards de l'industrie, qui garantit une intégration simple et facile au système d'information existant.


Il y a cependant des éléments à prendre en compte lors des choix de logiciels libres stratégiques.


Si l'aspect coûts est clairement un élément de choix qui peut conduire aux logiciels libres, il est principalement dû au fait qu'un logiciel libre existe souvent en version gratuite, librement téléchargeable. Mais ceci n'est que le le sommet de l'iceberg. Lors de la mise en production de logiciels il va falloir s'entourer de services dont l'intégration, où les possibilités de choix d'un partenaire seront d'autant plus grandes que le logiciel choisi est populaire et connu, ce qui conduira à des coups tirés vers le bas grâce à une concurrence saine. Mais il faudra aussi prévoir le support technique. La encore, la popularité du logiciel choisi augmentera la palette de prestataires de support possible. Le choix devra se faire suivant des critères très solides, et en particulier la capacité à s'engager sur des niveaux de service, la disponibilité 24 heures sur 24, 7 jours sur 7 (le pays ne s’arrête pas de fonctionner le week-end ou la nuit), et, éventuellement, la couverture géographique correspondant aux métiers que l'on exerce (un pays comme la France couvrant avec ses DOM et ses TOM une grande partie des fuseaux horaires et zones géographiques de la planète).


La plus part des services publics, que ce soit éducation, santé, ou gouvernement, utilisent déjà des logiciels libres. On les retrouve coté infrastructure, avec des produits comme la base de données MySQL, fortement appréciée dans le monde de l'éducation pour construire des plate-formes d'e-éducation en conjonction avec d'autres produits libres tels Moodle, ou GlassFish, le serveur d'applications très prisé des développeurs pour son adhérence au standard Java EE version 6 et sa simplicité de mise-en-œuvre. Linux est extrêmement présent comme système d'exploitation libre dans le datacenter, mais aussi sur le poste de travail. On retrouve des outils de virtualisation tels Oracle VM, issu de Xen, dans le datacenter, et VirtualBox sur le poste du développeur.


Avec une telle palette de solutions et d'outils dans le monde du Logiciel libre, Oracle se apporte au secteur public des réponses ciblées, efficaces, aux besoins du marché, y compris en matière de support technique et qualité de service associée.

Wednesday May 25, 2011

Picking your open source vendor

There are many reasons that may drive your company, division or service to decide to implement open source solutions, products or technologies for your IT. That is more and more an easy decision. Open source is being used all over the world, businesses, and governments alike.

The tricky part is not deciding to use open source, but rather to select which products to use and which vendor and/or system integrator you get them from.

Here is a list of some of the criteria you will want to take into consideration when selecting your vendor.

  • Strong financials and staying power. You want the vendor you pick will still be there for the whole duration of your project. Selecting an open source solution helps in that if your vendor disappears from the market, you can still find expertise to support your system, but it's still much better if the vendor is there and keeps driving the product development the way you expect it.
  • Enterprise class support, with global reach. In particular, make sure the vendor / integrator you work with can support your operations at any time you are conducting them, and in every location you are. If your service runs 24x7 all over the globe, the last thing you want to hear is that support only works 9-to-5 in one single timezone. If your IT is deployed in a location around the globe from your main office, it should benefit from support there as well.
  • Strategic relationship between your service and your vendor. Your  service or business depends on your IT. Your vendor should be involved strategically with you. The vendor should understand not only your IT needs, but your business needs, so that when you express new specific requirements, they are properly taken into account by your vendor the way you expect them.
It's not easy picking an IT solution. In fact, these criteria are very similar for open source and for proprietary software. The difference is that with open source solutions, you get the option of selecting alternate sources for support, maintenance, and future evolutions of your software and the guaranty that if one vendor has issues you can fall back to another without exit costs. It's like all the benefits of dual-sourcing your vendors... but with just one product and no migrating from one product to the other when changing vendor sources.

Wednesday Apr 07, 2010

7 Strategic Reasons to Use Open Source

Great reading on open source and why to use it at : http://solutionsfit.com/blog/2010/04/06/7-reasons-to-use-open-source-software/

Tuesday Mar 30, 2010

Piedmont makes Open Source legal, and preferencial

Fantastic decision of the Piedmont Regional Council which makes Open Source preferential in the region.

Monday Mar 29, 2010

Gordon Brown on Open Source

Taken from Gordon Brown's speech on Building Britain's Digital Future, what he says about Open Source :

"And rather than civil servants being the sole authors and editors, we will unleash data and content to the community to turn into applications that meet genuine needs. This does not require large-scale government IT Infrastructure; the ‘open source’ technology that will make it happen is freely available. All that is required is the will and willingness of the centre to give up control.

This bold new approach will transform the way services are delivered but, more importantly, it will be the vehicle through which citizens will come to control the services that are so important to their lives and communities.
"

I like that a lot! When Gartner (I seem to recall) claims that Open Source is what drives the European public sector market, this is the perfect example.



Tuesday Mar 23, 2010

Oracle Announces Latest Release of Oracle® Berkeley DB

Anybody still have doubts as to Oracle's commitment to open source? They just announced the latest release of Berkeley DB with support for Google Android!

And a new SQL API based on SQLite...

This is looking very good!

Thursday Oct 22, 2009

2020 FLOSS Roadmap version 2009 is out!

So the new version was published and announced about 2 weeks ago, right after the Open World Forum in Paris (quite an impressive event, with a very interesting speech from Mark Shuttleworth). Check out the new (2009 edition) of the 2020 FLOSS Roadmap! Very interesting reading!

Gilles.

Friday Oct 16, 2009

You know you've been using OpenSolaris too much when...

... when you start typing "pfexec" in Linux instead of "sudo" and wondering why it doesn't work.

Time to "alias pfexec sudo" for me. :)

Tuesday May 12, 2009

Why closed, proprietary platforms are to be avoided... whenever possible!

Those who know me know I am very much against Apple's commercial behavior. With the iPod, they sell a closed, proprietary platform, which is bad enough, but they also completely control what you can put on it.

The following article explains what happened to an author who wrote a nice application, and, after some updates of it, saw it banned from the Apple Store.

 Apple basically has right of life or death on the software you write for their platform. Even if they don't really understand what it does (the article explains why this is the case)...

Of course, you can always jailbreak your phone (which I recommend anybody stuck with an iPhone do as soon as they can) but this voids guaranty, and some may not like it...

I chose a phone with a truly open platform : Symbian OS. Open Source. Easy to write code to. And anybody can install what they want on the phone. And it's stable! Ditch your closed phone platform. Get one that is desgined with 21st century principles!

Sunday Apr 26, 2009

Building aMSN with audio and video on OpenSolaris - piece of cake!

I got tired of not being able to use webcam and audio with my friends on OpenSolaris... so I decided to tackle the problem. Blastwave's version of aMSN was very old... so there was no other option... get it myself and build it.

Turned out to be trivial...

Get the sources from : http://www.amsn-project.net/  and then ./configure, then gmake, then pfexec gmake install (my OpenSolaris box has already GCC and the GNU compiler suite installed). Simpler for all GNU / Linux source codes available out there.

First thing that happens when you run it is that it tells you it wants TLS to log in... so you install the SUNWtcltls package form the OpenSolaris repository with Package Manager... and in the advance preferences tab, specify that TLS is at : /usr/lib/tcl8.4/tls1.6 ... and voila... you can log in.

Of course, next thing is that there is no audio... so you figure out it wants Snack, the audio library for TCL... well, that too is available from the OpenSolaris repository through Package Manager. Just install SUNWsnack and restart aMSN. Then you can configure audio (preferences -> advanced) to use Snack...

For the webcam, it's even simpler. OpenSolaris includes USB-VC drivers for Video4Linux2, so plug in a high-end USB-VC webcam and aMSN directly supports it! Just go to the preferences->others menu in aMSN and edit the audio and video settings!

I love it when things just work!

Tuesday Apr 14, 2009

My first conference call with OpenSolaris's VoIP application!

Today I was scheduled to be on a conference call. I decided to be a geek and try Ekiga on OpenSolaris. It ships by default. Well, you have to install it from the default repository. It's just not called Ekiga, but Video Conference...

I started it. Gave it my Ekiga and FreePhonie account details (FreePhonie comes from my ISP and gives me SIP telephony for free to land lines all over Europe and other major countries around the planet). Once the details entered, I dialed the toll free number form Ekiga and voila!

Speaker sound was perfect. Microphone sucks on my Toshiba Tecra M2. Next time I'll test the fancy Logitech USB headset!

I love it when "technology-just-works"!


Wednesday Jul 23, 2008

Chosing the right license in the open source world

So you are now ready to start creating a product. This product will contain software. Software you will write, or have already written, but possibly also third party software that you will bundle with your own code, and maybe some hardware.

You need to start thinking, very early on, about a crucial element when using software.

Licensing.

You may already have made the decision on whether your software will be commercial or free, closed source, or open source... but you need to look at licensing issues in at least 2 very important places, in particular if you plan to include open source software.

  • How do you plan to license your own software within your product 
  • What license applies to the third party software you are bundling and how does it interact with, or impact your own software 

Many people tend to associate open source with only the freedom aspect it brings. But it also comes with a serious amount of obligations and responsibilities.

Selecting the right license is the work of licensing experts and lawyers. But I'll try to give some ideas on how to go about making reasonably good choices in this area.

First things first. The Open Source Initiative has a definition of what an open source license is. This definition is available at : http://www.opensource.org/docs/osd/. They also do the complex task of reviewing popular open source licenses and listing the ones that match the definition. This list is at : http://www.opensource.org/licenses/. It provides a basis for selecting licenses from, at least, a limited list.

So what is that makes an open source license. Let me start by quoting the 10 points of the Open Source Definition mentioned above :

---

The Open Source Definition

The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicized means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

The license may restrict source-code from being distributed in modified form only if the license allows the distribution of "patch files" with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.

The license must not discriminate against any person or group of persons.

The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties.

The rights attached to the program must not depend on the program's being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program's license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.

The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

No provision of the license may be predicated on any individual technology or style of interface.

---

As you can see, that's a pretty strong definition. Lots of things that must be done, and lots that can't be done, if a license is to merit the qualification of open source.

Not everything can be called open source. Good thing there is a definition.

So. How do you pick the right license for you? What are the implications?


Well, there are 3 main types of licenses available to pick from.

  • Type A : Unrestrictive licenses 
  • Type B : File-based licenses 
  • Type C : Project-based licenses 

Type A licenses, also refered to as “attribution licenses” are the ones with the fewest requirements. They allow unrestricted development of derived works. You can typically use type A licensed code in any way you like, embedding it into other applications with almost no constraints. Example type A licenses include the popular Apache or, the very simple, yet effective BSD (example from the FreeBSD project) license. One of my favorite ones (which I have yet to see used in common software is the WTFPL “Do What The Fuck You Want To Public License”.

One of the aspects that I've noticed about type A licensed projects is that despite the fact that the license doesn't mandate that derived works should be submitted back to the original project, they tend to generate a strong community feeling in the user / developer community and people still do contribute back to the original source commons. Which goes to show that you don't have to force people to contribute for them to do so.

Type B licenses are the ones that are normally considered as community fostering licenses. The point of these licenses is that when you take code from such a project, you have to contribute back to the project any chance you make to files from the project. You are free to add any new file covered by any license you want (as long as that license of yours doesn't conflict with the normal licensing of the original project files), but any existing file that you change needs to be contributed back to the project if required. Example type B licenses include Sun's own Common Development and Distribution License (CDDL) which covers OpenSolaris.

Many developers use type B licenses when they want to embed some open source project (say, an operating system) into a bundle (could be an appliance) which is licensed differently. Doing so, they have to keep the original open source project with its license, and thus, with source code available, even if they do modifications in the project files. But they can add their own files, drivers, applications, glue and keep those licensed as they want (even, possibly, commercially licensed).

Finally, type C licenses which tend to be project fostering licenses, are such that like type B, any file you modify from the original source commons keeps the original license, but also, any file you add to the project inherits that project's license. These license inherently seek to propagate open source by, in a way, contaminating what they touch. They are often qualified as viral licenses. Should you bundle your own software with a type-B licensed project, your own software automatically gets contaminated and turned into a type-B licensed code for which you also will have to publish source code as defined in the original project's license. This is great when you want the project community to benefit from any derived works built upon that project. But it can also have the side effect that people using code from these projects are forced into publishing their own intellectual property. Examples of type C licenses include the universally known GNU General Public License (GPL) which is used for example for the Linux kernel. Anything tightly bundled with a Linux kernel has to be licensed under the GPL as well.

In order to make this contamination aspect less constraining, there is a derived licensed based on the GPL called the GNU Lesser General Public License (LGPL). It is possible to link through specific means software to an LGPL licensed project without that software being contaminated by the original license. This enables one to bundle an LGPL project with non LGPL code and keep the licenses different for each part of the bundle. OpenOffice.org is licensed under the LGPL, enabling one to plug pieces of code into proper APIs in OpenOffice.org and keeping these plugins licensed the way initially planned.

A typical example of unplanned contamination would be an appliance vendor that makes small consumer devices that sell in hundreds of thousands of units. In order to limit costs, they elect to use a standard chip set that provides the basic functionality directly, then they pick the operating environment to put on it. For costs and simplicity, they pick en embedded Linux platform. Then they develop their own code and glue. They write device drivers for custom hardware, they write a complete GUI that directly plugs into deeply embedded aspects of the operating system, and device configuration, and they sell the whole thing as a consumer appliance. The problem is when somebody figures out that it's Linux inside... and since Linux is covered by GPL, that means that all the software that is deeply linked to the OS is also, necessarily, made GPL. First of all, they have to make the whole source code available (as per GPL, and any other open source license)... but worse, if they embedded other third party code, they can get into legal issues because that third party tool probably also must be made available under the GPL. It can get nasty. Because they didn't consider the implications in advance.

On the other side, sometimes, you WANT to use a viral license like the GPL. Sun has published the OpenSPARC processor under the GPL exactly with that viral aspect in mind. We want other companies to build fancy, successful, commercial products based on the OpenSPARC processor. We want them to not only benefit from the R&D we did to come up with the OpenSPARC processors, but also, we want them to bring their own enhancements, and contribute back to us the good work they throw into the processor. We want the next hot microcontroler based on OpenSPARC to benefit the whole OpenSPARC development efforts.

So as you can see, there are several types of licenses, each with very distinct characteristics. Choosing one isn't something you do lightly.

In order to choose the right license for you, you must first decide what you want to do with your own project. Deciding if you want to make it commercial, or not. Closed, or open source. You need also think about how you expect your users, and possible developers down the line might want to use or reuse your code into their own projects.

Then, if you are going to bundle your code with third party code, you must carefully examine the license you want for your code, and the available third party projects that fit your requirements and their own licenses. Make sure the one you pick has a license that is compatible with your selected license to avoid legal issues down the line.

As you see, choosing proper open source licenses (in products you will use, as well as in products you will develop) is not necessarily an easy task. Following the above guidelines will help you get a general idea. But probably the best single advice to give is to talk to a lawyer specialized in software licensing. They will help you pick the right license that is best for the model you have in mind for your product. Also, people like the FSF organize licensing workshops. For example, the FSF Europe is running a 'Licensing questions and other legal issues' workshop in Zurich, Switzerland on October 17th, 2008. There may be others in your region to chose from.

Wednesday Apr 30, 2008

OpenJDK 6 in Ubuntu Hardy!

 

So yesterday I had a very nice surprise. I moved my old home server from NetBSD (had been running that OS faithfully for the past 7 years - through a few hardware updates - but I've been bitten too many times by pkgsrc updates that broke most of GNOME and required heavy sessions of recompiling individual stuff to fix for my own comfort) to Ubuntu Hardy (I've been using Ubuntu on other laptops for quite some time, since version 6.04).

 

Basically, I first copied the 550GB of data from the 750GB disk of the NetBSD machine (since Ubuntu can't read the NetBSD filesystem natively) through the network to a new 750GB disk plugged into a Ubuntu machine... That took over 24H... Yech. Then I installed Ubuntu on a 200GB SATA disk and the new 750 GB disk in the small server that had previously been running NetBSD.

 

My first two steps were installing SqueezeCenter (for my Logitech Squeezeboxen music streamers) and SwissCenter (for my Pinnacle Systems ShowCenter 200 media streamer) which required some fiddling around because of Hardy's new AppArmor security scheme which messed up PHPMySQL... and Apache 2 who is new to me (the old NetBSD machine was running Apache 1.3)... I now have multimedia again at home. accessing

 

Then I prepared the P2P downloading stuff... aMule and Azureus... And that's where the cool thing happened. First, Azureus is directly in the Ubuntu repositories... which is nice. Second, when I installed Azureus, it naturally added the dependencies, which, to my big surprise, include... OpenJDK 6! Very nicely done! Completely transparent.

 

(As a note to Azureus authors : Because Azureus uses Eclipse's binary SWT for GUI, it is
not platform independent - which is stupid as it breaks one of the main
interests of using Java... so it wasn't available on NetBSD... which
is why I got used to using the excellent (and lightweight) Transmission BitTorrent GTK+ client. And as such, I guess I will, finally, stick with Transmission also on Ubuntu...)

 

So automatically, now, on Ubuntu, when needed, OpenJDK 6 gets installed... I'm curious to see how the updates will take place through the Ubuntu update manager. And with what delay compared to the official updates to JDK 6 from Sun. But this is very very good news for the Ubuntu users community, and for the Java world in general. From now on, one can assume that the official JDK will be available in Linux... transparently... just like that, when needed.

 

Java. There, for you, when, and where you need it!

 

My next steps include getting Apache 2 fully working with all the relevant virtual domains that I used to host... and also getting the SAMBA file server up and running for the family users on the home LAN. A few more nights of hacking fun in perspective and I'm all set!

 

Again... thanks Sun and Ubuntu for having made OpenJDK 6 directly available, no hassle, in Ubuntu Linux (and others, as I understand)! A beginning of a new era... Microsoft won't ship Java by default in Windows... fine. Linux will. Guess who wins? :)


Thursday Sep 13, 2007

Skype 1.4 on Solaris in a Ubuntu BrandZ zone!

At last! I got it working!

Since Solaris Express Developer Edition build 72 (you might have to wait for build 72 to be published), we have experimental support for Linux kernel 2.6 in a BrandZ zone!

Instructions on how to install are here...

What I did was install Ubuntu on a separate machine. Configured the repositories for Skype and Medibuntu. Installed Skype and Google Earth... then did the tar cjf from / as documented in the installation instructions for Linux 2.6 BrandZ zones... and created my zone and installed it from the .tar.gz archive on my Nevada b72 system.

When I did the zoneadm install, I got a bunch of error messages at the end... but despite that, network which was configured as DHCP in Ubuntu picks up the address I hard coded when creating the BrandZ zone (and store in /etc/zones/ubuntu.xml - my zone configuration file).
 

Note... I had to enable sshd in the Ubuntu zone for this to work.

And despite that, I can't just ssh into the zone... bash starts up when I do so... but doesn't give me the prompt... But I can ssh -X MyZone /command/to/run and run any X11 command...

So what I now do is run ssh -X MyZone /usr/bin/skype and I get Skype up and running.

Note that Skype 1.4 uses only ALSA and BrandZ only maps OSS... so no audio yet. :( But I can chat nicely

Skype 1.3 uses OSS... And with that one, in the Ubuntu branded zone, I get proper Audio!

We are making progress!

Gilles.


 

Wednesday Jun 13, 2007

Making Money Out Of Open Source

 
 

So you're considering writing your application and making it available in open source. But you're also hoping to make a profit from it. And, frankly, you're wondering how you're going to make a profit by offering a product where you make all the sources available for free. Rejoice! Quite a few people have had this same situation before and have come up with some pretty good ideas.

We're going to look at a few of them here.

I'm going to assume, here, that you've already sorted out what kind of licensing your software will be published under. If not, look for a soon-to-come entry in my blog about open source licensing and I'll give you some guildelines on how to pick the correct license(s) for your project.

Here are six of the most common business models around open source.

Dual license


Under a dual license model, you would publish your product in 2 ways. One would be an open source license, say GPL, CDDL, BSD, so free to download and use and modify. The other would be a different license, possibly a commercial one. In this case, you would probably elect to bundle, with your original software, additional features that bring value-add, justifying that a customer might want to purchase that bundle rather than download the purely free open-source block.

Some of the features that you could consider bundling might include :

  • Multiple dictionnaries for spell checking (case of Sun's Star Office, compared to OpenOffice.org which only comes with one dictionnary by default).
  • Fancy administration tools
  • Enterprise-class management / monitoring

Picking the right set of additional commercial features is critical to generating demand for the commercial version of your product, so should be the fruit of very serious thinking.

Subscription


Here, you aren't really selling a product, but rather services around your products in order to make it useable in enterprise deployments. So for example, you'd be looking at offering services like :

  • Support
  • Training
  • Installation
  • Integration
  • Customization

Your typical customer running a mission critical sales server would not want to do that without a very efficient support service available to help them fix things if their system breaks down smack in the 15 days before christmas when they make 80% of their yearly revenue... And they will pay for that kind of support.

Some companies like JBoss (now part of Red Hat) have become very popular using just that model.

Sun now offers most of its software products also under that model. You download and use Solaris for free, but we'll offer you world-class support contracts to ensure proper response to incidents should they happen.

Hosted

Think "Utility Computing". Some of your customers just don't want to run a datacenter. Let's face it, their company isn't in the business of running computers, it's selling the products they make or trade. So why invest hundreds of thousands of dollars in running a datacenter when others can do it for you. Well, that's where you come in. You make your software available for free. Fine. You even give away the sources. Better. But you (directly on your site, or through a partner hosting company) offer also that software as a service, for a fee.

Sun develops a free Grid Engine. You can download it. You can use it. But we've built a grid for you that you can connect to, and purchase CPU cycles on, in order to upload your applications on it, or use the ones we provide, to run your enterprise on by processing your data sets.

Companies like SalesForce.com also have a similar model

Consulting


This is one very nice area of the open-source community where everybody benefits from the work done. This model has led to the creation of many local businesses, as well as whole divisions of global comsulting firms, that specialize in delivering consulting services around existing open-source software. They will take a set of products that they consider being interesting by their standards, and offer a whole set of services around them

This is interesting in many cases, but here is a particular example of where it benefits the original software author. Suppose that the software author is a local company in, say Europe. They don't have the size to distribute and, more importantly, support, their product all over the planet. But if their product is sufficiently interesting, chances are that they will have users on every continent. So what do they do? Probably nothing... because in places where there are enough users that have shown a need for proper services around the products, there will likely be some small, local, but highly competent groups of people that will set up a structure to distribute, and more importantly support with services like first level support, integration, training... your product. You might even want to consider striking a partnership deal with these local structures and make some money off of it, to your mutual benefits.

Near where I work in Geneva, there's a small company called LynuxTraining. They do just that with their sister company LynuxSolutions.

Embedded


Some companies have found that they could build a very fancy product, but that they could gain a lot of time by not re-inventing the wheel, but, rather, by re-using something already available. In most cases, this will be something like an infrastructure component. Think about it. If you are going to build a computer, will you design your own CPU? Probably not (though in some cases, this has been known to happen). Well, same applies to things like an operating system. If you are going to build an appliance, you might want to use an existing operating system. You will pick that OS according to the needs of your appliance. Do you need real-time? You might pick something like QNX. If you're building an extremely secure security appliance, like AppGate's Security Server, you would pick Sun's ITSEC EAL 4+ certified Solaris 10. You might even want to build a vertical solution for office automation based on the open-source OpenOffice.org. Be careful what license governs the product you pick to embedd, as you might be forced to give away some or all of the source code of additional code you've written to make your whole product due to license contamination issues.

Stewardship


This isn't per se a business model. Rather, it's a way to generate indirect revenue. The point here is to drive, actively participate in, an open source project, to ensure that it becomes successful. If it does, you hope that the reputation of your company will increase from it, and that it will drive customers to you. It's not easy to live just from that, and you might want to combine this model with some of the previous ones above in order to ensure a viable revenue stream.



There. You have it. Of course, this isn't a definitive list. I'm sure that the open-source community with it's very bright minds will (probably already has) come up with new, more creative, models for making a living from their collaborative work. So will you.

Now you have an interesting subject of reflexion while you create your business plan that you will present to your future investors, that will show them a proper potential for profits!

 

About

gravax

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today