My two cents. I wouldn't trust software which is not open source. You cannot judge if it does its job well, especcially in long lasting use, like f.e. a database, how do you know if it still works if your table reach the million records and the table is 127 fields wide with on the second field a VARCHAR (127), I have seen many strange things in software products. What happens if a vendor gives up, or isn't interested anymore in the specific product, or is bankrupt What happens if a vendor decides to break backwards compatibility, or he is just clumsy?
An opensource product mostly is produced in a community, or at least, watched closely by a community. If that is not the case, than it is the same as a closed source, because a normal user cannot study or maintain the code, and is depending on the good will of the developers. Open Source controlled by a single person or company is almost the same as closed source. But good open source software products-developing, like from the Apache community, is very trustworthy, more trustworthy than a closed source vendor will ever will be able to be. It is also a good indicator, if a community looses interest, the open source product will be less trustworthy, its future becomes at stake. It is a public indicator, everyone can see it happen. This is often not the case with closed source vendors. Even a good financial position is no guarantee. Someone can buy the company, just to for the purpose to kill the products. For me, I always use open source software, always, never, never, never I use closed source software. Not because I read the source, I almost never do. But because open source causes other circumstances than closed source. And it feels safe, as long as there is a community, the product will continue to exist, and will be maintained There are some guidelines for starting open source projects. For example, develop it in closed environment, and if the product is more or less mature, than start community-building and open source the product. The concept of everyone starting from scratch and build without central directions a good product does not work. It is how ever possible to invite people or companies at a more or less matured product. It has advantages. It forces the developer to write good code, because he is planning to show it to the world. People coming into the product later on are skilled and serious developers. Their motivation is tested, because they had to read thousands of lines of code, to get the feeling. Often, when parties are hooking up to a matured product which is open sourced, that are companies, which have advantage when that product in stable way is on the market. Bert On 16-09-11 14:51, Sebastian Garde wrote: > I agree with you Thomas, > > Whether these tools are open source or just free as in beer (for > openEHR) - doesn't matter too much...for me it is far more important > that the tool does its job. > If there are open source tools that really do the job - fine....very > fine indeed, but if not, I for one, do not want to use tools just > because they are open source if we can have better ones that are just > free. > > Not sure where this discussion stems from, but I am reasonably happy > with the current Jira, Confluence and SVN approach and do not think > that changing this is a huge priority. > (It's not like there isn't anything on the foundation's priority list > at the moment :-) ) > But I may have missed the reasoning why openEHR's current tooling is > not sufficient in the first place? > > Sebastian > > Am 16.09.2011 14:22, schrieb Thomas Beale: >> >> For openEHR, Atlassian hosted solution JiraStudio (not open source) >> may be worth considering since it solves the problem of physical >> hosting without (in theory) causing much disruption, since all the >> tools are the same - Confluence, Jira (particularly) and SVN. >> >> Atlassian bitbucket (completely separate from Atlassian mainstream >> hosted tools) uses Mercurial, a better DVCS than SVN, but its issue >> tracking etc is minimal. >> >> For the price of more disruption, Github would be one place to go, >> and it is probably the best DVCS there is (it was designed based on >> the BitKeeper solution we used to use in openEHR). How good the >> project tracking tools are I don't know, but they are claimed to be >> good. The main thing that is needed is integrated DVCS, project / >> issue tracking (with configurable workflows, security etc), wiki, >> mailing lists and continuous build server. >> >> Whether having everything open source is fundamentally important is >> debatable - in principle it is nicer, but I am more interested in >> getting work done efficiently, not battling tools that are in early >> development (certainly my experience with most free issue tracking >> systems - maybe the Git one is better). >> >> - thomas >> >> On 16/09/2011 09:29, Ian McNicoll wrote: >>> Hi Tim, >>> >>> >>> Can you give some examples of good open-source tools in this area? >>> >>> Ian >>> >>> Dr Ian McNicoll >>> office +44 (0)1536 414 994 >>> fax +44 (0)1536 516317 >>> mobile +44 (0)775 209 7859 >>> skype ianmcnicoll >>> ian.mcnicoll at oceaninformatics.com >>> >>> Clinical Modelling Consultant, Ocean Informatics, UK >>> openEHR Clinical Knowledge Editorwww.openehr.org/knowledge >>> Honorary Senior Research Associate, CHIME, UCL >>> BCS Primary Health Carewww.phcsg.org >>> >>> >>> >>> >>> On 16 September 2011 00:09, Timothy Cook<timothywayne.cook at gmail.com> >>> wrote: >>>> Well, maybe you should consider real open source tools. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110916/7f954e91/attachment.html>
