First time here? Questions? Talk to members and volunteers right now! The Hospitality Club
...bringing people together!
Estonian  English  German  Spanish  French
Finnish  Italian  Lithuanian  Dutch  Polish
Brazilian  Portugese  Russian  Turkish  Ukrainian 
Sign up!
??Login


 Search? 
Google
Web hospitalityclub.org

 Quickgo
Forum > Technical Help and Questions > HC might soon be open source!
#0 HC might soon be open source! Mon 13 Aug 07 22:14:20
samm
Praha
Czech Republic
HC might soon be open source! We are reaching a consensus among programmers and
very active volunteers right now - the final decision will be made in a few
days. Now we would like to hear your thoughts: do you like the idea of HC being
open source, or do you see problems? Especially if you are a programmer, have a
legal background or have experience in open source project organization and
community management: would you like to be involved? Please send any thoughts
you have about this big step in HC's history directly to Veit.
Reply
#11 HC might soon be open source! Tue 14 Aug 07 20:09:44
noammeir
Kiryat Haim
Israel
oh one more!

I'm sure you know it better than me, but I think in purpose of making it safe
the open source should be available to members only and that's also with some
supervision of the volunteers although it is a bit against the open source
idea...

cheers :)
Reply
#12 HC might soon be open source! Wed 15 Aug 07 2:17:02
dante-gabryell
Bruxelles/Brussel
Belgium
Sounds like a positive move !
Reply
#13 HC might soon be open source! Wed 15 Aug 07 8:06:25
rheydy
Haag
Germany
Hi samn,
this is a wonderful announcement and a step in the right direction. I wish I
could help you, but my technical skills are non-existent.
Thank you very much, Samn!
Franz
Reply
#14 HC might soon be open source! Wed 15 Aug 07 13:22:12
neoman
LJUBLJANA
Slovenia
Hi samm!

I don't know if you got my mail, you didn't write back, so I'll point out the
things I did in my mail.

About the open source question, if you're considering releasing the code to the
world wide web there is a big chance of hackers being able to break into the
database - that means exposing ALL HC's members and their personal data. Are you
sure the code is "bullet proof"? I don't know about all of you, but I don't want
any of that - exposing all your private data and endless hours being spend by
programmers to fix all the bugs. IMHO I'd rather keep it under close guard and
keep the dev team small and super-effiecent.

Samm: About helping the dev team, you can contact me using the info provided in
my profile ;)
Reply
#15 HC might soon be open source! Wed 15 Aug 07 15:55:59
jgauthier
Montréal - Hochelaga-Maisonneuve
Canada
As an answers to all the skepticals about the security issues involved : the Mac
OS X kernel is Open Source! So far I can tell, it remains a safe platform,
security-wise. It certainly doesn't hold me back from using my mac book for
doing my bank transactions using in the process an other *huh* other open source
software  : firefox

The HC software is coded in PHP right? PHP is open-source. You can get the C
code and even create customs new functions fairly simply. ( altho it involves
lots of dreaded macros )

examples can go on and on. If there are problems with making HC open source,
security is not among them. In fact, I dont see any problems that would occur
anyways.
Reply
#16 HC might soon be open source! Wed 15 Aug 07 17:00:03
neoman
LJUBLJANA
Slovenia
Let me cheer you up, there are loads of exploits available for OS X kernel :)
But let's stay on the topic. I have to disagree, being a system admin for quite
some years now I've seen what can happen when the source code is leaked.
Security is by FAR the most important question here. If the code is opened I'm
afraid some PHP "experts" might think it would be funny just to deface the page
or some mind find an opportunity and steal the DB. Does anyone agree or at least
finds the question regarding the security important?
Reply
#17 HC might soon be open source! Wed 15 Aug 07 17:28:23
samm
Praha
Czech Republic
Yes, this is very important question. But i don`t believe at all in "security by
hiding sources" model.

1) Most of the SQL injection can be found w/o any access to source code, just by
inserting smth. in the POST/GET data and looking into results. Of course, source
access will speedup process, but not critically.
2) Most of the most critical holes was found in closed source products. Just few
examples - 
* DVD encryption, faulty algorithm developed by huge association was cracked by
talented scholar, in a few month after release. In opposite side you can look
into AES or blow/twofish algorithms, which was developed public. 
* M$ IE was exploited so many times that its even hard to count this. More than
this - very often time between known (!!!) exploit and fix from M$ was more than
2 weeks. In opposite side - firefox/mozilla - most of security faults was small
and they always was fixed in a days or even hours after known exploit or even
before this (just by auditors report).
*  Just compare Windows with OpenBSD ;-)
3) Database itself is internally protected. We are using encoder for the hidden
data. Encoder algorithm and source will not be published at all. More than this
- i`m thinking about more complex encoder which will utilize different codecs
for the data protection. Public source code will contain just a gap, "plain"
encoder, where input==output. So if someone will steal database (not a simple
task, btw), he will need to find encoder algorithm and crack it. I don`t think
that this can be done in a reasonable time by side person.
4) I`m sure that current code security is not on a high level (sad to say this,
but its true), and i`m sure than only active new volunteers may help us to
change this. We really need coders :) There are many very hot tasks which are
required for the our site. So, its better not to speak about problems, but solve
them.

And last note - if you want to be involved into the dev. process - you need
opensource model :) simply because i don`t know you and i can`t trust you and
without public access to sources i cannot share them with you :) so, things are
really very simple.

Reply
#18 HC might soon be open source! Thu 16 Aug 07 12:28:36
kiwiflave
Barcelona
Spain
Definitely the right move! If done properly. However, I doubt that this can be
achieved in a couple of days, it should be carefully prepared to make sure user
data is secured. HC is a far more lucrative network to be attacked (due to its
size) compared to other small networks working in an open source environment
already.

As active member and local volunteer of HC I think it is more important to find
the best sustainable solutions for the club. No programmer, though, so if you
tell me everything is perfect and safe, go for it :-)
Reply
#19 HC might soon be open source! Thu 16 Aug 07 13:01:05
babso
Brunswick
Australia
Actually, there are much bigger networks of users that are already open source. 
Slashdot.org is one of them, which has an enormous registered user-base where
member data is protected.  Open source means making the code visible, not
releasing the membership data.

HC treats member data very carefully and protects it heavily.  We understand
that when a user choses to keep personal data hidden, or only viewable to HC
members, that we need to respect that and do everything we can to enforce it.

And despite the poor quality of HC code in many places ( keep in mind this is
mostly poor quality in the eyes of a programmer, being modular, easy to
maintain, well written and efficient etc ), membership data which has not been
asked to be visible remains encrypted, as sam says.  Even if the DB was stolen,
the theif would realize the important data is encrypted anyway.
Reply
#20 HC might soon be open source! Thu 16 Aug 07 16:02:42
wuglusker
Sankt-Peterburg
Russian Federation
It's great! :)
Reply
#21 HC might soon be open source! Thu 16 Aug 07 17:18:46
samm
Praha
Czech Republic
There are many social networks with open source code. LiveJournal.com is just an
example. They have millions of users and many of them help to improve lj source
on the volunteers basis. 

>If Sam as a single (and rather new) volunteer says
>data is secure then I wonder if this is enough for a 300,000 members network
to
>relax, sit back and enjoy. 
If i will tell that data is not secure right now you will be more happy? Site
have some internal problems, which need to be solved. And this is not question
of moneys, its question of the developers time. I can`t do all the changes
alone. And we can`t get contribution from community, because sources are opened
only for "very trusted peoples".
Like me ;-) 
>Why not make a poll asking the members for their opinion, for example?
because most of our users are not develops. You can better ask them if they want
to see the site up, running and free. This poll will be much more correct.
> Sending feedback mails to Veit (as advised in the news at the front page)
might not 
>be the best solution to follow an open source policy.
Why not? Last word will be on Veit side - so, why not to write him? Also i
started this thread to make public discussion. Another thread is started on the
volunteers forum. So everyone who care is involved and can argument own
position. This is much better then poll with "yes/no/maybe" selector. Currently
security of the code is not very high, but data itself is protected. I`m doing
many of security related changes, but i can`t do all the things alone. We really
need community support, especially in the devteam.
Reply
#22 HC might soon be open source! Thu 16 Aug 07 21:54:05
ajt
Halblech
Germany
I'm happy to hear that. I sent a mail directly to Veit, but I'll also post my
thoughts here to encourage public discussion:

A few things to consider:

* Security. When previously non open source code is opened, it becomes easier to
find possible security holes. In large php applications there are often at least
a few unless the developers have been really professional and security-minded.
In the long term, open source model usually leads to more secure code than
closed source, but in the transition period you should prepare to be extra alert
and responsive towards possible attacks and bug reports. (Bugs can often be also
security holes even when they don't initially seem dangerous.)

* Integration of contributions. Independent developers will send you patches
implementing some neat new feature and ask it to be added to the official
version of the code and to be used on the HC site. The current developers need
to review these patches and consider which can be integrated, and it's a good
idea to have a test platform where features can be tested before adding them on
the main HC site. 

* Supporting services. Open source people are used to having mailing lists or
discussion forums, access to cvs repository (or other version control system)
etc. which help in developing the software. You'll need to choose whether to
provide these yourself or have the code hosted in one of the hosting services,
for example at SourceForge (http://sourceforge.net/), Google
(http://savannah.nongnu.org/) or Savannah (http://savannah.nongnu.org/).

* Licensing. As you probably know, there is a large number of different types of
open source licenses. There are two main categories: "bsd-like" which allows to
include code to programs which have a different license (including proprietary
software) and "copyleft" which requires that modifications need to be published
under the same license. GPL is the most common license in this category. Please
note that the publishing under the same license is required only if one
redistributes the code further - it's possible to run a service with modified
code without publishing the modifications. (There are other licenses which have
a bit different conditions, GPL version 3 also has an option to restrict running
such services without publishing the code.) Generally I wouldn't worry too much
about the license choice but it's a good idea to pick one of the popular and
widespread licenses, because that makes it easier to make new software by
combining code from different programs. I am not a lawyer but I have some
background in licensing so if you need more specific advice I can try to help.

* Copyright assignment. You will need to think about whether you require
contributors to the official version to assign copyrights to some organization
or whether they keep their copyrights. This is mainly relevant if you would like
to relicense the code under some other license in the future. Both models can
work well - e.g. Free Software Foundation (FSF) requires assignment for its
projects (GNU software) but in the case of Linux kernel the developers keep the
copyrights themselves.

* Openness in general. It's possible to have a very closed organization which
publishes open source code, or a very open organization which chooses to keep
code closed, but often open open goes best together. It might be a good time to
also consider which other aspects of HC should be made open and how (and which
should not be made open). I'm thinking about things such as financial data
(income and expenses) and decision making.

Regards,

Arto
Reply
#23 HC might soon be open source! Fri 17 Aug 07 0:17:41
zaferkandemir
Aachen
Germany
I agree that would be a nice, even superb move, as known from many different
examples as samm mentioned, i would vote for being opensource, both for the
developer side and for the member side, i mean i feel it might as well help the
usage of the HC...
just imagine a kind of interaction between Kcalendar or Gcalendar with HC :)
or even more and more ;)

so good luck!
Cheers!
Zafer
Reply
#24 HC might soon be open source! Fri 17 Aug 07 10:09:56
samm
Praha
Czech Republic
2@ajt - thanks for your message, with very detail and interesting comments. Just
a few notes:

I`m 100% agree with your security position. I will try to minimize risks. My actions will include (but not limited to) clear backup/restore strategy, some initial code cleanup (already in progress), file and processes audit. Also i think that we will change encoder before going open source to much more stronger one. And i have idea about "early adoption" period when source will be opened only to a few number of peoples which will agree to review and audit the code.
Contributions and test server: this task (i mean dev. server creation) is already in progress, we will launch dev server with test database. Currently dev. forum, wiki and svn already launched. Most trusted developers will even get shell access to it. It will be synced with the open source SVN and will not contain any sensitive data. Also it will be run in the "virtual" space, XEN or OpenVZ, still not sure.
Developers portal: we already registered our project @ sf.net, also i filled request for the developers.berlios.de project, it will be used as backup portal. I don`t like savannah - it is buggy and featureless.
Licensing: at my and most of the developers opinion apache license is good for our project. It is more bsd like than gnu like. I think that gnu license will cause more problems that it will solve in the feature. And i don`t believe that someone will fork our code in it current state to create new social network - this will cost much more time and moneys then to write code from beginning using modern frameworks and good code style. So, in current situation license mean not too much. Apache License 2.0 is very easy to read, popular and permissive, so it can be used there.
Copyright assignment: yes, still open question, i don`t want to touch it. For me - any variant is ok. Anyway, i dont think that this mean too much with apache license. Currently i put (c) Hospitality Club in the source code headers.
Openness in general: may be nice idea, but please don`t mix ideology with development tasks. Current situation is very clear - current dev. community is unable to put HC into modern web 2.0 world. Also many bugs and miss features (e.g. Unicode support) was never fixed, simply because past developers used latin-based languages and side developers like me was unable to send the patches. As you can see Unicode migration take ~3-4 days of one developer time and cause only some minimal regressions, which was fixed very quickly. So, let`s take organization moments out this thread - i don`t to be involved in any conflicts between personalities or even networks. I just want to make this site better, thats all :)
P.S. If you want to join development - plz. drop me a letter.
Reply
#25 HC might soon be open source! Fri 17 Aug 07 12:30:58
grappig
Amsterdam
Netherlands
If you choose the Apache License v2.0 you will unfortunately miss out on 
compatiblity with the GPLv2. I think releasing the code under a GPLv2 compatible
license could lead to more cooperation with other projects.

GPLv3 is compatible with Apache License v2.0. So we can see if it's possible to
move towards the GPLv3 on other projects that are now using GPLv2 (or later).
Reply
#26 HC might soon be open source! Fri 17 Aug 07 12:43:04
ajt
Halblech
Germany
> I`m 100% agree with your security position. I will try to minimize risks. My
> actions will include (but not limited to) clear backup/restore strategy, some
> initial code cleanup (already in progress), file and processes audit. Also i
> think that we will change encoder before going open source to much more
stronger
> one. And i have idea about "early adoption" period when source will be opened
> only to a few number of peoples which will agree to review and audit the
code.

This sounds good, as well as the development server without any sensitive data.
Finding auditors is a well-known problem in the whole open source world (and in
proprietary software too, many companies don't tend to do much auditing because
it's costly) but I hope it'll work out well.

> Developers portal: we already registered our project @ sf.net, also i filled
> request for the developers.berlios.de project, it will be used as backup
portal.

Are you sure you'll need both your own dev server, sf.net portal AND the backup
portal? I'm slightly worried that the two latter ones would cause overhead so
that people would have to check out and feed changes to both, and they might
become out of sync. Yes, there should be backups of the data in sf.net, but two
portals being online in parallel doesn't sound so good idea. Or is the
berlios.de site constructed so that you can automatically mirror the data from
sf.net without manual work?

> Licensing: at my and most of the developers opinion apache license is good
for
> our project. It is more bsd like than gnu like.

At least I'm perfectly okay with this. Apache is a popular and well-known
license and therefore a good choice. Personally I don't have a strong preference
towards either bsd/apache/x11 style licenses or towards copyleft-style (GPL)
licenses - they both have their places. And you're correct in pointing out that
copyright assignment question is less important if the license is Apache rather
than GPL.

> Openness in general ... So, let`s take organization moments out this thread

I agree, it's better to keep this thread focused on the code, security and
developer services.

AJT
Reply

Previous     New topic    Reply    Forum Overview    Next

1-5  6-10  11-15  16-20  21-25  26-27    Show All    

Change language: Deutsch - Eesti - English - Español - Français - Italiano - Lietuviškai - Nederlands - Polski - Português - Português (bra) - Русский - Suomi - Türkçe - Українська

Sign up - Contact - Countries - Disclaimer

Copyright © 2000-2012 The Hospitality Club. All rights reserved.