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
#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
#27 HC might soon be open source! Mon 10 Sep 07 7:25:34
valmid
Montréal
Canada
Lest you get impatient, I thought I'd let you know HC is getting open source,
under Apache License. I think the programmers are a bit behind schedule for
fixing the most awful security holes (register globals mainly), but there's no
turning back now anyway. Educated guess is all files but maybe two or three will
be on SourceForge some time this month.
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.