Comments on HKJUG Exco Blog: hkjug.org

> 1. is it a must to host under hkjug.org?I don't ...

2008-03-25T19:02:25.111+08:00

> 1. is it a must to host under hkjug.org?

I don't feel strongly about this. It would be nice, but I'm afraid this requirement will seriously restrict our options.

> 2. is it a must to use hosted service? i.e. we would not consider hosting our own server

I would "strongly prefer" to use hosted services wherever possible. Maintaining our own server is a serious commitment. It also means we would need to find sponsorship ASAP in order to cover the hosting costs.

Thanks A LOT for your ideas! :-)Before I'm convinc...

2008-03-25T10:33:11.791+08:00

Thanks A LOT for your ideas! :-)

Before I'm convinced by your point 2, I'm going to maintain our server for some services. I agree very much if it is possible, use hosted / SaaS service. For the exco blog, email, calendar, DNS etc. we are using hosted service already.

For public services, I strongly want to host under hkjug.org. So the SaaS service provider should support custom domain name (such as blogger). Google Sites redirect the user under google's domain and I don't really like it. There is a hosted wiki provider WikiDot.com that allows us to host our content under hkjug.org. Well, it's the best hosted wiki provider afaik, but just not as good as the non-hosted software.

So there are two key decisions:
1. is it a must to host under hkjug.org?
2. is it a must to use hosted service? i.e. we would not consider hosting our own server

My current decision is based on "yes", and "no" respectively. Sounds like you vote for no for the 2nd question.

re. pt 9, I don't meant to build the next myspace/facebook or blogger/wordpress or flickr on hkjug.org. I only expect people who want an identity as a part of the HK Java community to use the service, and I expect they use it to share stuff with other Java users in HK. e.g. sb may do a research on a Java open source cluster project and write his notes on the hkjug.org wiki under his own space. Certainly, people can use the service in whatever ways they like, it's up to them.

re. crowd, I've just dropped it from the roadmap. They reply to me saying the product is offered to open source project but not community. Anyway, we won't use as I found that its Jive Forum support is outdated and doesn't work on the latest Jive Forums, and I've almost finished my implementation of the Jive Forums Group and User Manager.

Great ideas, Mingfai! A few thoughts:(1) Making th...

2008-03-25T06:19:41.299+08:00

Great ideas, Mingfai! A few thoughts:

(1) Making the site easy to maintain needs to be a high priority. From past experience, it's very hard to find anyone with a lot of time to invest in maintaining a web site. (As William can confirm, we had big plans for hkjug.org when it was launched in 2000, but didn't have the resources to execute them.)
(2) From your post, I'm not sure if you were thinking of maintaining our own server, but given (1) I'd suggested avoiding this if at all possible, and instead using services that we don't have to host ourselves such as Google Apps.
(3) Hosting: Personally I doubt that the physical location of java.net is the reason it's slow, in my experience connections to the US are fast. I'd suggest not limiting ourselves to HK hosting since this will seriously limit our options for hosted apps--see (2).
(4) I agree that a wiki would be ideal for maintaining the site.
(5) Since we're a Java User Group, it certainly makes sense to use Java if possible. However, I'd still think ease-of-maintenance is an even more important consideration--see (1).
(6) I don't see why we should exclude software that is free but not open source--after all, many of us make a living from closed-source software, no?
(7) Re. Confluence, can we get a hosted site, or would we need to host it ourselves? If we can't get a hosted site, what about something like Google Sites?
(8) Same question for Jive Forums.
(9) Personally I think there are enough free sites for blogs and photo sharing, I don't see much value in hkjug.org providing this functionality.
(10) Regarding user identity, there's not yet an ideal solution to this problem, but I'd suggest OpenID is most promising. Confluence claims to support OpenID via Crowd. As for discussion forums I have no idea if any support it as yet, but at least we might be able to find one that has it on their roadmap. The same goes for other kinds of applications.