Open Source Considerations

We are examining the benefits and risks of open source licensing to small software companies like mine. In this post, I'm going to present what we've learned and questions we have about open source licensing in order to elicit feedback (comments, ideas, suggestions) from our readers.

What is Open Source Licensing?

First, for those who don't know, let me define what the term "open source" software licensing means. It is, in essence, a variety of licensing schemes in which the owners of copyrighted or patented software let others use and distribute the software under the terms of a particular license. There are many different open source licenses, which vary widely in what is free and in what others may or may not do with the software.

Dan Bricklin (inventor of the first electronic spreadsheet, Visicalc) describes it this way:
In pretty much all cases of open source, the user of the software gets access to the source code [i.e., the underlying instructions] used to create the software. Differences are in what the user can do with that source. In many cases they can make modifications to the software and use the software so modified. In some cases they can distribute the changes, in other cases they can only let the original owner know of the changes to be possibly added to the next release. In some cases the users can distribute the software (with or without changes) as they please, in others they can only distribute it under certain conditions, such as without fee and with public access to the modified source.  
Some of the desirable 'freedoms' for the software from the user's viewpoint include:
  • The freedom to run the program for any purpose
  • The freedom to study how the program works, and adapt it to your needs
  • The freedom to redistribute copies
  • The freedom to improve the program, and release your improvements to the public.
Some of the restrictions that people put in their software licenses include:
  • Requirements to maintain the attribution to the original author(s) along with the software
  • Restrictions on the type of license that may cover redistribution
  • Restrictions on the type of licenses that may cover other software included with the software when redistributed
  • Restrictions on the uses of the software, such as non-commercial only.
There are many arguments about the reasons why various combinations of rights and restrictions should be in a given license. While one may argue about which are "better" for society as a whole or for the company in particular, there is a choice to be made and creators of new software can make them as they please. [Reference]
Some of the least restrictive licenses seem to be promoted by the Open Source Initiative (OSI). The licenses OSI approves allows anyone, for any purpose, to freely modify and redistribute the software in its original or modified (called "derived") form. Other open source licenses have restrictions. For example, while the Creative Commons Noncommercial-Share Alike 3.0 license grants licensees the right to freely share (copy, distribute and transmit the software) and remix it (make modification to adapt it for their particular needs), it has the following requirements:
  • Licensees must attribute the software (also called the "work") in the manner specified by the licensor, such as stating the licensor's name and contact information
  • The work may not be used for commercial purposes (the licensee cannot sell or otherwise use the software to make a profit)
  • Anyone who alters, transforms, or builds upon the work must use the same or similar license as the current one if they with to distribute the resulting work to others.
The licensor may, however, give permission for these conditions to be waived.

Note that there are dozens of other open source licenses, including those that restricting derived work and free sharing. Very complex indeed!

What are the Risks of Open Source to an Inventor?

With all this complexity, why would a software inventor want to license an application as open source? After all, there's considerable risk in doing so.

Being the inventor of the PHP system and head of a company, due diligence requires that I consider how we would survive if we give away our invention for free after spending tens of thousands of hours of development effort on top other substantial costs (i.e., two decades of overhead, legal fees, etc.). Wouldn't it be business suicide to (a) reveal our trade secrets to potential competitors who have much deeper pockets than we do, (b) give them the right to use our patented processes and copyrighted materials for free, and (c) allow them to make a profit from our work without any compensation to us?

Well, some of these issues can be mitigated by using a license such as the Creative Commons Noncommercial-Share Alike 3.0. But even if other software vendors are prevented from stealing and profiting from the inventor's ideas, open source does not necessarily mean the inventor or his/her company will be fully protected and will gain financially from using open source licensing. So, do the benefits of open source outweigh the risks?

What are the Benefits of Open Source?

Despite the risks to the software inventor, I like open source licensing for a number of reasons. For one, it has the potential to reach and engage a large body of collaborators who can create a community who donate their time and expertise to expand and improve the original software system--and do it, ideally, for the common good. This is very important to us for several reasons:
  • Since the PHP system has been built from the "bottom up," it is designed to evolve continually by incorporating and integrating an unlimited diversity of data & information, analytics, and decision tools to help fill the knowledge void in a way that improves worldwide health by addressing the specific health needs of people across all cultures and nations. But being a small company with a discontinuous/disruptive innovation, and lacking the means (the money, work force and other resources) to organize people around the world for such international projects, means we need a cost-effective way to collaborate with other software developers and subject matter experts (clinicians, researchers, educators, translators, etc.) around the globe. Joining forces with international groups of collaborators across all healthcare disciplines (including all forms of physical, mental and mind-body illness, wellness/prevention, Eastern and Western approaches, and alternative medicines) would:
    • Enable the PHP system to realize its potential to provide a wealth of valid, reliable information that promotes the development, sharing, and use of vital health-related knowledge tailored to the people's specific needs throughout the world.
    • Reduce development costs, optimize usability, promote region/culture-specific customization and enhancements, and increase product security and reliability.
  • An open source approach also promises to move us toward accomplishing our company's core mission: To promote better health and wellbeing worldwide--including addressing the needs of the poor in all nations--thorough better use of better knowledge. We believe our technologies enable us to achieve this mission because it offers a cost-effective way to bring together loosely connected networks of people who share information, models and knowledge via a peer-to-peer (node-to-node) communication architecture. Because our technology consumes minimal resources, there is no need for expensive broadband, high-power computers, or costly software architecture. In fact, all that's needed in most situations are low-bandwidth (e.g., slow dial-up) e-mail and a desktop (or web-enabled) spreadsheet application. The e-mail and spreadsheet software handle the automated collection, exchange, integration, analysis and presentation of huge amounts of cross-disciplinary health information. In addition, they provide comprehensive decision-support tools enabling consumers and their sick-care & well-care professionals to make better, more reliable diagnostic and treatment decisions. Where money is tight and conservation of resources is important, costly/complex solutions aren't viable, but our solution is.
One way open source licensing would enable us to offer our technologies to help people in underserved regions is by affiliating with non-profit organizations such as Open Health Tools, Partners in Health and Nyaya Health.

Additionally, open sources benefits end-users (consumers/patients, healthcare practitioners, hospitals, wellness coaches, researchers, etc.) by avoiding vendor lock-in, lowering costs, and delivering more reliable products through code that has been peer-reviewed and improved.

Is Embracing Open Source a Way to Realize Our Vision?

The potential of open source for improving worldwide health, therefore, is enormous! Yet despite all the benefits, reality dictates that a software company must make money to survive. It's tough enough trying to introduce discontinuous/disruptive technology because it threatens the status quo, requires a paradigm-shift in people's way of thinking, and calls for expensive "missionary marketing" (in which market demand is created when no one knows you exist). The brute reality is that I've been struggling for the past 18 years—at great personal expense and family sacrifice—to have our innovation widely recognized as a useful tool for improving healthcare value (higher quality at lower cost). This has not been due to any defect in our technology, but rather to the reluctance of institutional investors to back the long-term development and marketing of radical innovations. Take, for example, this quote from one investor group: "We applaud your motivation and intentions to create a comprehensive system that would certainly be helpful to society and provide a well needed 'solution' to our healthcare system. However, the business plan … may be far too ambitious, and the…risk…exceeds our comfort level."

So, while we've been making steady progress for the past two decades, we have not come close to realizing our grand vision of helping make the world a better place by improving the health and wellbeing of all peoples because we've lacked the considerable resources needed to turn such a vision into reality.

The question now is: How can open source licensing enable us to survive financially, so we can continue on our noble mission through international collaboration?

One thought is to sell consultancy services to other software developers, e.g., by offering workshops, courses and training sessions to those who want to learn how to develop and improve PHP-based applications. Another is to sell the PHP system to commercial clients under non-open source licenses (including low-cost software as a service models), along with our libraries of assessment questions. In addition, we would offer our patented CP Split™ technology (which describes a unique way to distribute information using a spatial syntax* data structure) under an open source license as a component of the PHP system only, and we would license it for a small fee for development of any other applications.

Well, that's about it for now. I welcome any feedback about open source risks and opportunities, as well as specific suggestions as to a path forward.

Part 2
* Warning – This footnote is very technical. The term "spatial syntax" is a shift from the traditional paradigm based on (a) tabular/tuple data organization models used by relational databases and (b) markup tag definitions used by XML documents. Instead, it uses predefined data arrays stored in delimited text or spreadsheet files, which are then rendered using templates that apply formatting instructions based on the data locations/positions (e.g., referencing the data by their cell locations in a spreadsheet). This "spatially-based" paradigm is a proven disruptive technology. What makes it proprietary is that it uses a method for spatial addressing in which a rendering template, which contains formatting instructions: (a) consumes a data file whose contents have been arranged in such a way that the template "knows" the spatial positioning of each element in the data file, and then (b) applies the associated formatting instructions based on the data locations.

There are multiple ways to generate a data file that enables an associated rendering template to use spatial addressing to apply formatting instructions to the data elements. Thus, this method goes beyond mere spatial addressing, and on to establishing associations between such a "report-ready" data file and its corresponding rendering template(s).

[Note: To leave a comment, please make sure cookies are enabled.]
Go to next post


Steve Beller, PhD said...

Note: These comments, along with the original post, were moved from another blog to this one.

John Norris said...
Great post Steve...and it can be quite a puzzle as to how to protect and encourage one's work.

If you haven't already, you might post a comment to there are quite a few folks on that list that might be able to help.
7:39 PM

Steve Beller, PhD said...
Thanks much for your comment and advise, John. I will post to openhealth today.
7:12 AM

Joris said...
Interesting to read your thoughts on a similar process we went through several years ago, Steve.

You might find this an interesting read; The Beekeeper (

The company I work for, Bika Lab Systems, is a professional open source service provider, it has it's own GPL'ed LIMS products, and generates its income from (consultancy) services to our clients, like development, implementation and support.

I would recommend you go ahead, but choose your license carefully!

You're welcome to contact me at joris at bikalabs dot com, if you would like to discuss this further.
12:22 PM

Steve Beller, PhD said...
I truly appreciate your input and offer of assistance, Joris.
12:33 PM

Shah Family Business Ideas said...
Steve, we've talked a few times about and open source strategy for your firm and I'm glad you're considering it. By going open source you'll be able to move faster into the market, gain more credibility, and still be able to protect your IP through patents and such if needed. Check out use of the "Freemium" business model and you'll make good money, too which is important to keeping a technology and solution alive. Good luck.
6:51 AM said...
Congratulations for your work.
I got here through, a prominent website that applies open source principles to law research.

I know this comment may seem somewhat pedantic at first sight, but your project name seems to me a bit unfortunate (in the context of open source) because of the longstanding existence of another open source project that bears exactly the same name as yours.

I'm talking about the open source PHP programming language (, which is wildly popular on the internet, it's designed to be an extremely easy tool to build dynamic websites. (websites such as Wordpress and Facebook are built using PHP, to name just a few)

This name clash situation will probably make it difficult for your project to be found on the internet, which greatly diminishes your chances of reaching a massive public.

There have been other such occurences of open source projects nameclashing before, they are generally resolved very amicably. The most notorious such occurence happened between the open source database called Firebird, and a -then new- open source web browser called Firebird.
After a brief period of resolution, the web browser project started using a new name... that is what nowadays the public knows as Mozilla Firefox, which eventually became very popular on its own right.

Best regards,




8:43 AM

cybervegan said...
Sounds like a really sound, ethical project you're running there!

There is another choice you may find useful to know about: you can "dual license" - provide the software under as Open Source, using a strong license (like the GPL) and offer the same software under a more "business-like" license for a fee.

Any changes a GPL licensee makes to a program must be fed back into the ecosystem when they distribute (i.e. give away or sell) the product - and thus you get to share in their improvements. If they want to keep their improvements to themselves, they have to buy a closed source license from you. You can tailor this to your needs.

If you have patents on your methods, you need to know that software patents are not enforceable world-wide, and that certain licenses preclude them or mean that you will be effectively waiving your patent rights when you release the source code.

Several very successful products use this model - The MySQL database, for instance - and they also sell consulting services to support their product.

I would tend to visualise your software as a "viewer" for your data libraries - maybe sell subscriptions for the updates (like Red Hat do). Just because you Open Source your software, doesn't mean you have to do the same with your data, which I think is where the real value probably lies. Would it be correct to say that the software would be useful on its own, but vastly more so with up-to-date data? Bear in mind, thought, that once you have opened up the application, you can't then lock-in the data or say that you can only use *your* version of it, or your software to process it.

Why not get in touch with Pamela Jones at - she may be kind enough to publish an article for you for comment by our community - with many people more astute than me!

But before you do *anything* speak to a good lawyer about your plans.
Maybe run it past the Software Freedom Law Center too.

9:02 AM said...
For further reference:

The PHP programming language appears 4th in the TIOBE programming language popularity index chart.
9:03 AM

Steve Beller, PhD said...

Yes, I've thought about the name confusion myself. The fact is, I'm not tied to the PHP acronym, although it does describe our application well. It is quite possible that we will end up changing the name, or just dropping the acronym. This may be something for whcih the open source comminity would be helpful.

Thanks for you critique!
9:19 AM

Steve Beller, PhD said...
Shahid: I appreciate your comment. As one of the most knowledgable people I know concerning health info technology, your support means a lot. We will look into the Freemium model. Thanks much!

John: I posted to the Open Health blog and received a wonderfully stimulating and challenging response from Fred Trotter, to which I'll respond today and post on this blog. Thanks again ...
9:28 AM

DoctorMO said...
The open source world is complicated. But the Free Software world isn't nearly so complex because it encompasses the philosophies as well as the technicalities. When most people talk about open source they are actually talking about Free Software.

I wouldn't use a Creative Commons license for code though, not the same kinds of protections.
9:36 AM

Anonymous said...
You describe some Open Source licenses as allowing redistribution and some as not allowing redistribution. I'm not sure this is accurate. I believe the term Open Source is a trademark of the OSI, and as such should only be used by projects/licenses that allow redistribution. You'll notice that Microsoft has adopted the term Shared Source for it's own licenses that don't have OSI's blessing.

Good luck whichever way you go.
9:49 AM

Steve Beller, PhD said...

We will certainly consider the dual license model you mention. Thanks for the heads-up!

I do have a patent on some of the software methods, and yes, I do realize they are not enforceable worldwide. I’m also beginning to understand that certain licenses preclude patents or waive such rights. Interestingly, my patent contains no code, but does describe several unique methods. In any case, I do not want the fact that there is a patent on certainly underlying processes to prevent realization of its potential to improve health worldwide!

Your description of our software as a "viewer" for our data libraries is a nice, simple way to say it. To add some specificity, it’s a highly interactive viewer—that can operate online (via a browser) or offline (as a standalone desktop application) using broadband or dial-up—which is able to incorporate any number of modules that tailor the presentation of the data libraries for personalized views. In fact, a viewer may be tailored based on the end-users role (type of healthcare provider, wellness coach, consumer/patient, researcher, administrator, etc.), as well as ones reading level, language, level of knowledge, region, etc. It can also double as a “publisher,” to send data and information (asynchronously) to “subscribers” in a application-to-application architecture using secure e-mail (or ftp) in node-to-node (peer-to-peer) networks. And the data libraries can contain information from just about any source and in any format, in addition to the thousands of “biopsychosocial” assessment items we’ve developed thus far.

Yes, it would be correct to say that the software would be useful on its own, and that its usefulness will increase by continually updating the ever-more up-to-date data, evolving the algorithms used to analyze the data, and customizing the views for presenting that data.

I certainly will contact Pamela Jones and the Software Freedom Law Center.

You have very helpful. Thanks again.
10:07 AM

Steve Beller, PhD said...

You said "You describe some Open Source licenses as allowing redistribution and some as not allowing redistribution. I'm not sure this is accurate."

You are the 2nd person to have pointed this out to me. I stand corrected! Thanks. That's why I changed my the part of my post that says some open source licenses inlcude those "probiting derived work and free sharing" to "restricting ..."

I believe my confusion came from things I've read such as:

Open source licenses may be broadly categorized into the following types: (1) those that apply no restrictions on the distribution of derivative works (we will call these Non-Protective Licenses because they do not protect the code from being used in non-Open Source applications); and (2) those that do apply such restrictions (we will call these Protective Licenses because they ensure that the code will always remain open/free)." Reference

Anyway, I hope my post is now more accurate. Please do let me know if there are any other inaccuracies.

Such issues confirm the need for sound legal advice.
10:28 AM

Karl O. Pinc said...
Should you go with the GPL you get the following benefits:

You get a powerful legal support team, specifically in the Software Freedom and Law Center, but most significantly in the huge numbers of software developers and companies that have a vested interest in seeing the GPL upheld.

You get the benefits of copyleft, competitors who utilize your work must compete with you on your terms, on a level playing field.

The preceding two points mean that you have an overwhelming advantage should a rival attempt to appropriate your technology.

You also get access to a vast code base, all the existing GPLed code and GPL compatible code, that you can incorporate into your product.

In some ways it's like joining a giant franchise.

From the customer side the advantage of FOSS is transparency. This is particularly true if you open your development process, making publicly available your code as you develop it, having a publicly available bug tracking system, and using publicly available mailing lists to both coordinate development and provide customer support. If you do this you can't lie to your market about what your program does or how satisfied your customers are or what features are at which stage of development. This means that your customers will trust you, something that can't be bought.

Transparency also reduces friction in the marketplace, making it easier for prospective customers to make decisions. The potential customer can contact your existing customers on your mailing list, can gage the size of your customer base, and can generally all-around determine if your product meets their needs. The transparency benefits you directly because you get feedback from potential customers detailing their needs and concerns regarding your product; feedback that would otherwise be difficult and expensive to come by. Making your product available for download does the same, it makes it easy for the prospective customer to get involved.

Frankly if you do not open your development process you lose many of the benefits of FOSS.

In general FOSS leads to greater economic efficiency in the market. Hence, the down side. You cannot reap excessive profits. You are limited by the value you add as a service provider and as a guarantor of warranty to those who wish such.

P.S. People without cookies enabled cannot post comments, and cannot tell why they cannot post comments.
11:11 AM

Ed said...
Dual-licensing considerations:

If you go with dual-licensing (personally, I whole-heartedly recommend this. There are a number of companies out there who would be willing to use various open source products, except for the fact that they're open source), you need to consider the open source license with that in mind.

Specifically, while I normally recommend the GPL, it can have an unfortunate consequence: if a GPL user sends you a patch, they will generally license that patch to you under the GPL. That can put in a legal hurtle to applying that patch to a proprietary distribution.

As such, if you use the GPL as your OS license, you have three basic options:

1. The commercial licensed code is identical to the OS licensed code. The commercial licensees do not get a redistribution option through their commercial license. This tends to reduce interest in the commercial license to only those who would insist on it. As I understand it, this is how ReiserFS was distributed, as well as at least one of the other Linux kernel modules (iptables? Can't remember for certain. Something networking related.)

2. The code that's in the commercial version but not open version is in separate modules, which are either loaded at runtime or dynamically linked. GPL users can't submit patches to that code because the GPL users don't have that code. Commercial users, if they have access to the source, have a requirement to submit patches with authorization for you to distribute them under the commercial license. Sendmail does this - although sendmail uses the BSD license for their open source branch.

3. Only accept patches if the author gives permission for you to use it in both products. I should have an example for this, but I'm blanking on it.

Personally, I'd recommend the second option; from a maintenance perspective, it's pretty much necessary if you're going to provide any software value-add with the commercial license and you want to retain what sanity you have. It limits what kinds of value-add you can provide with your commercial license, as things that would need to be core to the main program cannot be in separate modules. However, those sorts of features generally don't stand out so much anyway.

Karl, thanks for the heads up on why I couldn't post.
12:31 PM

Steve Beller, PhD said...
Doctor DO, Karl, Ed – I thank you all, as well. I’m going to investigate, think about and synthesize all the suggestions being posting here and, in few days, I’ll come back with a follow-up blog post sharing my thoughts.

And Karl: I never realized Blogger required cookies be enabled for commenting. I appreciate you pointing it out.

I'm beginning to think this kind of support is indicative of how people in the open source community help one another, which is a wonderful thing!
1:08 PM

John Norris said...
I've been pleased to have been able to learn a lot from these supportive folks. The seriousness and rigor that I've found is both challenging, as you rightly put it, and refreshing.
1:47 PM

Karl O. Pinc said...
The trouble with dual-licensing under the GPL is that it discourages code contribution. Why should I assign my rights to you when I don't get a piece of the profit? You might be better served by using the BSD license in those portions of the code that you wish to add proprietary extensions.

Note that dual licensing is not necessary if you wish to warrant your product. It only seems applicable if you wish to resell to those who themselves wish to deliver a proprietary product. Requiring code contributors to assign you copyright is necessary if you wish to accept contributions to your own proprietary product or wish to take code contributions to redistribute to a customer that will make the code proprietary.

I take a bit of issue with the notion that Open Source licensing is complex. Sure, it's as complex as all of software license law, if you write your own license or copy the license of somebody else who's rolled their own. If you use one of the "standard licenses", the GPL (v2 or v3), the LGPL, the modified BSD license Open Source licensing is dead simple because so many others have passed down that road before.
2:03 PM

nitrogen said...
I got here from Groklaw as well. Regarding what Cybervegan said:

If you have patents on your methods, you need to know that software patents are not enforceable world-wide, and that certain licenses preclude them or mean that you will be effectively waiving your patent rights when you release the source code.

I believe it is worth noting that, from my understanding of the GPL, you don't waive your patent rights by releasing under the GPL, you simply grant a license to use those patents in any GPL software. This may not be what you want, and I may be wrong, so please do continue your research. I hope this helps to reduce confusion rather than adding to it. Please refer to the GPL FAQ on the Free Software Foundation's web page for more information.
6:46 PM

MylesJ said...
We are in a different industry but have the same kinds of questions. I see a difference between a utility program or tool and a line of business application. You have the additional overhead of medical secrecy enforcement.

Let us say that someone uses your software in a mashup that reveals a third parties history. Maybe someone adds a "feature" that sends the results of every lookup to them. You may have a problem if the judge is stilling looking for the tubes on the internets.

I think that this is one of the reasons to consider providing a hosted solution and keep control of the code. You could create a web service and an SDK to split the difference
1:42 PM

Steve Beller, PhD said...
nitrogen - Thanks for you input. I'm still processing it all in mind and writing a synthesis, which I'll be posting. One thing I'm exploring is a dual-license option, which seems similar to what you're saying.
1:58 PM

Steve Beller, PhD said...
MylesJ - You bring up a good point: How to prevent a licensee modify open source (OS) software in such a way that it jeopardizes the inventor and the other OS contributors?

I believe there a provisions the licenses to prevent this by, for example, requiring all modifications to be publically disclosed, at which time the OS community would demand the person's license be revoked. It could also be stipulated in the license that any modifications be compiant with HIPPA.

Can anyone help address this concern?
2:08 PM

andres said...

I believe the worst part of releasing open source is not being aware of where the business model of your product lies.

e.g, think of Asterisk, the amazing voip-hybrid pbx, Digium made the product. All others made money. Digium missed to understand the business around it, people didn't.

I love and promote OS, but need to live as well. I won't release my new software as an OS product until I am sure that I am good enough to provide good services on at least an important portion of the services around it.

In your case, if you are interested in not letting your product fly in the hands of other people, make sure you have the infrastructure to deploy, project manage, and support new clients.

10:33 AM

Steve Beller, PhD said...
Thank you, Andres.

I am confident that we can provide excellent services to the OS community on the important aspects of our technology.

I realize this is a big commitment of time and resources, and that revenue from these services would be considerably less than the potential profit of selling products close-sourced.

We are willing to accept this tradeoff as long as the potential benefits to all involved are also considerable.
11:03 AM

care3g said...
On your comment above at you reference a text that is not so accurate.

There are Open Source Licenses that are, in fact, really restrictive and only allow you to see the code and even modify it but you must pay a yearly fee to use even your modified version (i call those the fake Open Source); then you have the common Open Source as defined by the OSI ( which give you more or less freedom but enforce that openess somehow; and you have the real free licenses like the Public Domain and some BSD-like variants which allow you to do almost anything.
4:39 PM

Dr Aniruddha Malpani, MD said...
You might want to talk to Neil Cowles, Tolven CEO, at

Neil will be a Keynote Speaker at the World Congress Leadership Summit on Transforming Healthcare through Open Source Innovation in July 2008.

You'll meet lots of people tackling the same issues you are !

Dr Aniruddha Malpani, MD
Medical Director
HELP - Health Education Library for People
Excelsior Business Center,
National Insurance Building,
Ground Floor, Near Excelsior Cinema,
206, Dr.D.N Road, Mumbai 400001
Tel. No.:65952393/65952394
2:09 PM

Steve Beller, PhD said...
Thank you, Dr. Malpani, for the recommendation to speak with Neil Cowles. In fact, Neil and I did speak last week. I was truly moved by his compassion, sincerity and knowledge. Fred Trotter at Open Health is another great resource for folks considering OS.

Wonderful people like them and others, with whom I've been communicating with the OS community these past few weeks, support the case that OS is the way for us to go!
5:15 PM

Time Attendance System said...

Thanks for such social platform which give us variety of idea to explore ourself technically .This exposure give benefits to everyone to fit or to survive in global market which is very essential in the global era.

Aldus Logan said...

Open source is an enterprise resource planning (ERP) system whose source code is made publicly available. The open source model allows companies to access the ERP system's code and customize it using their own IT department instead of paying extra for vendor customization services and licensing, as is typically the case with closed source programs.

Time Attendance System said...

I believe Web time sheet software makes the complete employee time clock tracking task easier. Its easy to update, approve and maintain the time sheets in no time.Time Attendance System

Time Attendance system said...

Thanks for such social platform which give us variety of idea to explore ourself technically .This exposure give benefits to everyone to fit or to survive in global market which is very essential in the global era.Time Attendance System

Nafis Islam said...

Design portfolios are available in numerous forms. historically, they need been print-based and one thing you'd carry to a consumer pitch or meeting.
graphics design
open source software
graphic design portfolio
responsive themes
drupal themes
graphic design portfolio examples
design portfolio
open source softwares
open source database
best graphic design

jim said...

nordauto |

autoproj |

autoskola-hyvnar |

cashforjunkauto |

ez-autorental |

traveltims |

travelredsea |

phototravels |

traveldomain |

denver-travel |

jim said...

You should only work with affiliate companies that offer fair commissions and good products. Don’t take on a product with an affiliate company that gives less than 20% commissions. Good affiliate companies understand that good efforts deserve higher commissions, and will cause you to work harder for them. | | | | |

jim said...

Appointment setting services can be used by all industries and they can greatly benefit businesses in all different types of markets. However, there are certain industries that tend to benefit the most from this type of service.

vivan edward said...

Thank you for posting the great content…I was looking for something like this…I found it quiet interesting, hopefully you will keep posting such blogs….Keep sharing
chiropractic soap software