Improv and KDE

When I announced the Improv ARM computer on Monday, I did it on my blog which is also syndicated to Planet KDE. That's because there is a very significant link between Improv and KDE.

People are shifting their computing time from traditional large laptops and workstation desktop systems across a breadth of devices. Not only are people using tablets and phones more, they are also using online services more and more.

For that least several years this trend has weighed on my mind in relation to desktop oriented Free software and, in particular, KDE software. How can we ensure KDE software can be where people are using computers today and tomorrow? I'll call this the Big Question.

The answer is not an easy one, in that it's actually a set of answers and it implies work for all of us. Some project teams within KDE, such as Plasma, Calligra, Marble and Kontact (among others) have been starting on addressing the Big Question. We've been creating software that can scale down to smaller hardware and creating user interfaces that work with various interaction patterns, such as touch, in addition to our traditional focus on the WIMP paradigm. Some have also targetted platforms and operating systems that are fairly foreign territory to be able to access the audience that use them; the port of Qt to Android can be seen as an effort in this line.

This is a lot harder, however, without hardware in your hands that you can easily work with to test your software on. So the Big Question leads to the Small Question: What hackable ARM-based hardware exists that supports KDE software out of the box?

Until Improv, the answer was simple: none.

Improv will ship to people with KDE libraries as well as Plasma Workspaces included. We will support that software, take bug reports, issue updates, etc. Community support is something we are fostering even now as well. We have an open build service farm that we've been using for quite a while now to create KDE packages for Mer OS for both ARM and Intel targets. There's even a Mer SDK you can install locally to get started on image creation if that's what you're interested in doing.

So if you'd like to be able to see how your software runs on a small ARM device; if you'd like to see how thin clients accessing your applications might perform; if you'd like to experiment with alternative form factors .. Improv is there for us.

Being able to offer a full computer for $75 that can run KDE software to an acceptable level, and in the process give a good impression of it to those using it, could be invaluable in promoting KDE technology to students and makers alike.

Improv is also great for non-GUI development. It makes an awesome whisper-quiet, low power server for the home or small office. These kinds of services, properly integrated with rich client software, is an area which will become increasingly important to the future of KDE and other Free software desktop software.

Improv is a product that can open the doors to the world of ubiquitous, device-centric computing for KDE. No more waiting for a big vendor to be kind to us and take our needs into consideration, no more buying devices never intended to run KDE software and try and shoehorn it in.

This is why Improv should be of prime interest to, and receive the support, of the KDE community and those who care about the success of it.

Read More

Introducing Improv

Improv: the powerful, open hardware development board

Make·Play·Live is happy to share some great news with you today: our first hardware product, Improv, is available for order today. As the name suggests, Improv is all about making new things. It is the perfect board for prototyping and creating small, powerful devices.

A combination of three attributes sets Improv apart from the crowd:

1. Power: Dual core CPU, lots of storage, powerful GPU and modern software
2. Modularity: Improv is actually two plug-and-play parts: a CPU card and a feature board
3. Community: The feature board is freely licensed as Open Hardware, is supported with community infrastructure and contributes to the technologies on which Improv is based.

In broad strokes, this is what makes Improv unique and exciting. It is the perfect starting point for your hardware projects.

A view of Improv  from the business end of the card

Power

The hardware of Improv is extremely capable: a dual-core ARM® Cortex™-A7 System on Chip (SoC) running at 1Ghz, 1 GB of RAM, 4 GB of on-board NAND flash and a powerful OpenGL ES GPU. To access all of this hardware goodness there are a variety of ports: 2 USB2 ports (one fullsize host, one micro OTG), SD card reader, HDMI, ethernet (10/100, though the feature card has a Gigabit connector; more on that below), SATA, i2c, VGA/TTL and 8 GPIO pins. The entire device weighs less than 100 grams, is passively cooled and fits in your hand.

Improv comes pre-installed with Mer OS, sporting a recent Linux kernel, systemd and a wide variety of software tools. By default it boots into console, so if you are making a headless device you needn't worry about extra overhead running that you don't need. If you are going to hook it up to a screen (or two), then you have an amazing starting point with choices such as X.org, Wayland, Qt4, Qt5 and a full complement of KDE libraries and Plasma Workspaces.

Improv unplugged undocked

Modularity

Improv takes advantage of the open EOMA68 standard to deliver a unique design: the SoC, RAM and storage live on one card (the "CPU card"), the feature ports are on a PCB it docks with (the "feature board"). The two dock securely together with the CPU card sitting under the feature board nestled in a pair of rails; they are undocked from each other by pushing a mechanical ejector button.

This means that you can use the CPU card separately from the feature board, have multiple CPU cards for different projects or even upgrade your Improv as new CPU and feature boards become available. Not only is this better for the environment, but it gives you ultimate flexibility.

The software is similarly easy to bend to your will. You can boot into the included Linux-based operating system and decide whether to stay at console or fire up a full OpenGL accelerated graphical environment. Or you can choose to boot something else entirely from the SD card slot, via the USB OTG port or by flashing a new bootloader and/or OS image to the built-in NAND.

Additional hardware add-ons such as VGA connectors, keyboard kits and cases are also in development and rely on the openness and modularity of Improv. Through its modular design, Improv is designed to last and grow.

More than just a product, Improv promotes community

Community

Improv is the result of a community effort. Collaboration within the EOMA68, Linux netbook and ARM communities helped to deliver and prove the hardware design, while working with software communities such as Mer, KDE and Linux have allowed us to deliver amazing software on top of that hardware.

Production, branding, marketing and retail are all enabled by collaborative interaction within Make·Play·Live's Partner Network. Via this network, we bring together individual community participants as well as entrepreneurial and corporate support, without which Improv would not be possible.

The schematics for the feature board are licensed under the GPL and will be made available in tandem with shipping so that you can learn about the design and even extend it in new ways. We are also ready to help motivated makers who come up with great ideas for new feature boards, add-ons and entire devices through the process of prototyping, manufacturing and delivery. This is not a device you buy and are then left on your own with. Improv is a starting point from which to create amazing things that can take flight.

To support you in this, we provide sleek online discussion forums, the Open Hardware Registry (OHR) and the Mer Community Open Build Service (COBS). The forums are administered by Make·Play·Live community members and provide a place for people to discuss projects, ask questions and share answers. OHR allows makers and vendors to register globally unique IDs for their hardware projects, much as the USB-IF does for USB, only without the fees, bureaucracy and limited ID space. The Mer COBS, which is jointly sponsored by Make·Play·Live and Jolla, provides an effective way to build and distribute software for Improv.

This is only the start of the community infrastructure to support your needs as makers. Videos on Youtube showing tricks, techniques and project ideas for Improv will appear weekly. These will feature people who were key in the development of Improv; in time, we will also feature videos highlighting community contributions. Future plans include infrastructure to help you share your hardware projects with others, a community driven knowledge-base and local user groups supported with project concepts and planning.

Creating sustainable models

One of the biggest challenges we have identified in the free software and open hardware movements when it comes to consumer and mobile devices is sustainability. Hardware costs serious money to produce and involves engaging with a supply chain that can be challenging to work with. We know, because we have spent the last two years working on some ambitious open hardware projects.

From that experience we have built a network of hardware, software, procurement, manufacturing and branding expertise. Starting with Improv, we are opening up that expertise to others who would like to turn ideas into reality.

Improv is also an opportunity for us to invest resources into relevant free software and open hardware development. The Mer Open Build Service, for instance, will be partially funded by proceeds from Improv. Software developers and open hardware designers working on similar projects will receive continued sponsorship and funding thanks to sales of Improv. Ultimately, we expect new products to spring up as others use Improv, continuing the cycle of building sustainable models in the open device world.

When you purchase an Improv you are not only getting a truly great device to work on, you are also supporting the process of creating quality free software, open hardware and the services which will enable others to do the same.

Elegance, freedom and power in one package.

"Shut up and take my money!"

Improv retails for US$75 plus applicable shipping and taxes. That includes the feature board, the CPU card and a commitment to engaging and fun makery from us to you.

We will start shipping to North America and Europe near the end of January on a first-ordered, first-shipped basis. Needless to say, each manufacturing run produces a limited number of Improvs and we expect the first lot to sell out quickly. To order your Improv today and get in on the first public shipment of devices, visit the Improv information page and click on the purchase button.

Read More

Kate has won

A couple of weeks ago Martin Gräßlin noted that I use vim and not Kate in a G+ discussion. Suitable shown up, II decided to give Kate another serious run. I do this every couple years, and it has indeed gotten better every time I've used it, but ... you have to understand that I'm fighting a long term addiction to vim here ;)

So I checked myself into editor rehab and forced myself to use Kate on two projects recently. I have to admit that I'm a convert. A lot of the keyboard controls I'm used to from vim translate over to Kate; if I turn on the vi mode in Kate it gets even better.

What really sold me though were two things: sessions, and the built in command lines (plural).

Kate lets you give am editing session a name. You can open and close sessions, and Kate tracks the files you have open, etc. There is also a Plasma widget and krunner integration, so I can now hit alt+f2 and type "kate" to see all my saved sessions. With autocompletion, of course! So: alt+f2, "kate mpl", , bam! right directory, 30+ files open. Beauty.

The other must-have for me are the command lines. I live and die by the terminal, so having one around is crucial. Kate allows having a Konsole session right in the editor window. This is collapsable, so it doesn't waste space when i don't need it, but is always right there when I do. The killer feature is that it follows me around as I move between files in the GUI. I can do all my git foo, scp'ing, grep/find'ing, etc. in that window, of course, but perhaps the best thing is that `kate ` opens the file in the kate window, adding it to the session. My workflow is preserved!

There is also another command line in Kate: the Kate command line. This lets you tell Kate to do things with nifty little commands. As a vimmer, this feels so very, very natural. :)

A lot of things I'm used to doing quickly in vim can be done quickly in Kate. It's not 100%, but then Kate is better at some things compared to the default vim, too. For instance, Kate has the filebrowser sidebar with all the usual KDE goodness such as breadcrumbs, autocomplete, etc etc. Kate is fast, scriptable, detects files changed behind its back, autorecovers if your X session dies (not that that ever happens to me when working on things like the lock screen with X screensavers *cough* *cough*). It also has those nifty over scrollbars and various gewgadgetry that is just little sprinkles on the cake.

Not that I won't use vim from time to time still ... (he writes, looking at his various ssh sessions in various konsole tabs...)

Read More

what trains are for

Today I had to go to Milan .. and back .. by train. That's a total of eight hours planted in a moving seat. I won't explain why I had to do this crazy little trip (it's related to our announcement on Monday) but there I was .. at least I had a power plug and a table to myself. Which meant I could catch up on various bits of work, and when I needed a break from that I happily hacked on random Plasma bits.

One thing I did was clean up some issues with the lock screen. The new QML based lock screen would show the password dialog even if you had set it to not require a password. There was also some fun you could have by connecting a second monitor, something I only noticed while reading the code fixing the first issue.

One tester noted a bug in my first run at this, so this evening once back home I spent some time pounding on it in every direction I could. I can no longer get it to misbehave, so that's a good thing.

There's also a patch on reviewboard, thanks to Thomas Lübking, that should get pushed shortly that improves the screenlocker when using multiple screens and the (legacy) X screensavers.

Given the nature of the screenlocker, it would be great if those of you testing pre-releases could also keep an eye on the screenlocker for new unwanted behaviors that may be introduced by these changes. As I said, it works well here and it's been tested by at least one other person already ... but more eyeballs equals fewer regressions.

In any case, that's one more set of issues that are cleared up for the Plasma Workspace 4.11 long term release. The fixes are not streaming in at an alarming rate, but they are trickling in at a nice steady pace, which is the entire point of these things.

Read More

bodega: partners, aggregating audiences and YOU

I did a quick screencast today showing what "partners" are in Bodega and how they work. It's one of the many ways that Bodega is a little bit different from other similar systems and as such a screencast can't hurt to help people understand how it works. I will cover other aspects of Bodega in future, so feedback on what would make these videos more useful to you is welcome.

A primary concept with Bodega is that of audience aggregation. Many of us have audiences, but few of us have big audiences, and even fewer have huge audiences. Unfortunately, the economics of selling content only works with larger audiences and even for those who aren't selling stuff it's often more of an incentive when your audience is larger.

Since Bodega can host all kinds of content and then show only selections of that content, it naturally allows for content aggregation. To understand why imagine that there are three solitaire card games which have configurable backgrounds, card deck graphics and game rules. Each of them uses similar image files to decorate the cards shown on screen, but each of them uses a different file format to describe how the games work. Now imagine that all three of these projects integrate Bodega into their game to allow people to get new card decks, backgrounds and game rules.

In Bodega, people could happily publish backgrounds and card decks. The backgrounds might just be regular ol' wallpapers, or they might be a specific type of image for board game "mats". Other people could publish game rules that are specific to one of the three card games. While the backgrounds and card decks would have a common tag noting what they were, these game rules would be tagged with the applicable game.

A card game developer would then create a store in Bodega that shows all backgrounds, all card decks .. but only the game rules for their game. Each of these could be put into a separate channel in their store so when the person playing Mystery Science Solitaire 3k presses the "Download card decks.." button they see just card decks and not backgrounds or game rules.

Everyone is happy .. but something interesting has happened in the process. Instead of trying to motivate an artist to make card decks for your special card game, they just have to be motivated to make a card deck for any of the card games. Perhaps they'll be more motivated if they know that their work will show up in multiple applications and therefore get in front of more people. Probably, right?

In such a case, the artist doesn't even need to know about Mystery Science Solitaire 3k to make it better, so the app developer also wins.

Now .. forget about card games for a moment and think about entire Linux distributions. Or independent musicians and authors. Or small device makers. Yeah.

Together we can aggregate audiences and increase the sustainability of each of our interests in the process. The key word is together.

We're going to be writing a "integrating a Bodega store into your system" HOWTO and then I'll be making it my mission for Q1 2014 to get as many projects, people and companies doing exactly that. Between now and then, I'm looking for early adopters that we can work more closely with to refine that HOWTO.

If you are involved with a project that you think Bodega integration would be perfect for, please contact me by email at aseigo at kde.org. Your project can be web based, focused on the traditional desktop or mobile; it can be a single application or a bigger system. All I ask is that it has had a public release and has some user base already, even if small.

Read More

#merweek

Make·Play·Live's website is counting down to ... ?

As Dario Freddi noted in his G+ stream today, the week of the 25th is shaping up to be #merweek. There will be not one, not two but three product releases that week featuring Mer OS over the course of the first three days of the week from three different companies, all of whom contribute to Mer OS. It is going to be an exciting, fast, hot week for anyone interested in embedded and mobile devices, whether as a user or a maker. 

We'll be kicking off the festivities on Monday morning at 17:00 UTC (09:00 PST) as we unveil the first Make·Play·Live product, at long last. The only thing I can reveal right now, other than it uses Mer OS by default, is that it is not a tablet. 

For everyone waiting for Vivaldi: We have not discarded the tablet concept. In fact, the final product is frustratingly close to completion but we missed the the holiday season time window. The Vivaldi journey, however, was crucial for informing the product we will be making available on the 25th.

Supporting this announcement will be a brand new Make·Play·Live web site, which currently is counting down the seconds until 17:00 UTC on Monday the 25th. This new site will serve as a visible hub for the business network we've been putting together throughout 2013, a place for those looking to harness the capabilities of the Bodega content system to get hooked in and productive as well as a community gathering and support node for .. well .. you'll find out on the 25th. ;)

The day after that, Ispirata will be releasing a device development system designed for embedded systems needing quick development and long term support which they've christened Hemera. The day after that Jolla has their product release.

It's going to be one hell of a week ... #merweek

Read More

fewer "omg what did i just do?!" in plasma desktop's panel

In Plasma Desktop, some people (clicking wildly, apparently) sometimes right-click click in a random spot of the panel and get the widget's context menu. This includes a "Remove this " entry with a big red "x" icon, but they click on it anyways and *poof* .. there goes their window list (or whatever).

Since Plasma Desktop 4.x is in long term maintenance mode, which means we're supposed to be making it more stable and reliable, I figured I'd spend a few minutes thinking about this problem. So I set aside one of my morning showers for this. Now you know what I do in the shower. Other than clean myself, of course. :) This probably explains my moderately frequent half-hour showers.

So ... exercise in problem solving time! Do we:

a) Always start Plasma Desktop in "Locked" mode?

Bad answer: it means that to do almost *anything* with your desktop you now need to unlock it. Many features become hidden and the user is robbed of discovery opportunities.

b) Lock just the panels!

Not only does (a) apply, but this introduces huge complexity .. and not just in the code (where now different containers need to be treated specially) but also for the poor end user who now has to figure out how to lock/unlock every freaking part of their desktop separately.

c) Allow the panel to tell the widgets when not to show their close item in the context menu. Then, when you click on the toolbox icon which gives you access to various configuration settings, have the panel tell the widgets that they should now show the remove item.

We have a winner! 

Apparently it's not the most obvious idea in the world as people have been clamoring for (a) and/or (b) for some time and to my knowledge *nobody* has suggested (c). As a maintainer, my first job is to say "no" to ideas that will have undesirable side-effects. My rather less important second job is to identify (or in a worst-case-scenario, *gasp* come up with ;) ideas that will work .. or at least not fail. (The two are not always the same thing.)

I've been saying "no" to (a) and (b) for a while now, while suggesting that if someone can come up with a better idea, let me know. Well, it ended up in the shower and answer (c) was the result.

How much work would this be? One line in libplasma (checking a value) and three lines in the plasma-desktop shell (toggling that value in time to the configuration UI). Yes, a whopping four lines of code.

This demonstrates two things:

1. Plasma is amazingly flexible and designed in such a way as to make implementing solutions to problems easy
2. That the real work is often in realizing what the solution is in the first place

This improvement will land in the next maintenance releases of kdelibs and kde-workspace.

Read More

panel.autohide = true

I tend to use Plasma Desktop in its default configuration since that is what most people are subjected to. However, when I first started contributing to kicker (kde2/kde3's panels) I started doing so because I used autohiding panels on multiple screens and .. there was  room for improvement. Since autohide panels are not the default, I no longer used the feature on a daily basis; basically only when bugs were reported would I turn it on.

Well, I decided to spoil myself the other week and turn on autohide on my one lonely panel. Besides having that screen real-estate back for the first time in many years (ok, on a 19" monitor it isn't that much real estate. ..) I got to enjoy all the improvements that had accumulated.

There is the nice blue glow that appears and intensifies as you move the mouse closer. These days this is a kwin effect and boy is it nice and smooth. It's the kind of feedback I could only have dreamed of with kicker.

The next thing I noticed was the hiding animation itself. With kicker we just moved the panel around visually on-screen. This was very funny when you had two screens next to each other as you could watch it move from one screen ... to the next! See, it wasn't really hiding. We fixed that with Plasma Desktop: it actually really hides now. We went one step further and delegated the animation to the compositor. This allows it to be silky smooth and take as little CPU as possible. Ah, performance ...

With kicker, autohide panels would wake up the system a number times per second. This was because it polled for the mouse position to know when the mouse hit a screen edge. Waking up a process means waking up the CPU, which is not good for your battery, and it means keeping it always resident in memory which impacts the performance of multitasking. It's much better when process remain silent, and so with Plasma Desktop we use input-only windows and XEvents to trigger the unhides. Beauty.

Well .. sorta. These input-only windows can interfere with other windows in specific situations, though we've minimized those cases over time. Still, we're going to make this better .. and get rid of the X11 dependency all at once (which is important for supporting Wayland) by moving screen edge handling to the compositor, which in our case is, at least by default, KWin. This means that the compositor will be able to coordinate the desktop shell's screen edge needs with the window managers with .. well .. anything that needs screen edge handling. All without fusing the shell and compositor.

One more gripe I had with kicker is that if you were especially evil (or just unlucky) you could trigger subtle bugs with the hide/unhide mechanism. I worked a lot of annoyances and bugs out of that code, but it was never quite 100% perfect in 100% of cases. So far, I've been unable to trip up Plasma Desktop's panels. Yay.

So autohide panels may not be the biggest feature or the most required feature, but it's been a nice little frill for me these last couple of weeks. :)

Update: I totally forgot to mention what is probably my favourite feature of all: now whenever there is a notification  or something requires your attention, the panel containing it automatically unhides so you notice and then re-hides itself ... unless you aren't interacting with the system. In that case it stays unhidden until you move the mouse or type something (or generate some form of input) .. so you never lose a notification just because you were away from your desk. MAGIC!

Read More

on introducing new ideas to free software communities

Over the last two weeks I've gone through two "new idea introductions" with two entirely different Free software/hardware communities. (I used the word "two" three times in that sentence, and were I a slightly odder sort of person I might try to use the word "three" four times in this one but I'll refrain at just three. ;) Both went fairly well, and perhaps that's because it was not my first time around.

I've had my fair share of opportunities to introduce new ideas to a Free software communities in the years I've been a participant. In the process, I've learned a number of "do"s and "don't"s (the hard way) and I thought I'd take a moment to share some of them here in hopes someone else might find them useful.

Tell the community first. This may seem like an obvious one, but I can't count the number of times I've seen someone waltz into a community's common area and tell everyone what they had just done in hopes of support. Without naming names, I saw this done just last week and it turned out rather poorly.

There is a saying that goes, "it is easier to ask forgiveness than permission". However, when it when comes to introducing plans and ideas to a community, this is often very bad advice. It too easily puts people into a position where they feel a binding decision has already been made on their behalf, and when that happens people often stop listening effectively and start talking loudly. This is, needlessly to say, not good for communication.

There are even people who will push back on the idea simply out of principle, no matter how good the idea is, as a means to reclaim their (or the community's) right to input and dissent.

It is therefore far more effective to approach with a proposal rather than a decision. It is also usually far wiser to do this before actions that may appear official or binding are taken. Even if you've done a lot of work already on your concept / idea / implementation, approach the community with the humility required to present it as a proposal rather than a statement.

This is actually an area of constant conflict-creation which I attempted to improve over at freedesktop.org ... to no avail. My proposal was accepted in words and reject in actions, despite over a year of patiently working on the concept in an open and collaborate manner. That brings us to the next point quite neatly:

Be prepared for "no". Sometimes people will reject an idea. Sometimes that idea will be a really, really good one. Sometimes it won't. You'll always think it is a really, really good idea though otherwise you wouldn't have proposed it, right? ;) That can make accepting "no" really difficult, but it is important to realize that you can't force a community without breaking it.

This doesn't mean you have to take the first "no" as the final answer, however. Usually "no" comes in the form of a question or an objection. Be ready! Before presenting your idea, play your own devil's advocate and think of all the ways you might counter your idea. Better yet: present your idea privately to a friend or three that you trust and have them take a good, hard run at it. This will help you be ready for when you get a "no", because that will enable you to more effectively: (... hello, segue!)

Engage in dialog. When presenting an idea, others may have valid ways to improve it. They may be able to inform you how to make it more appropriate for that specific community in ways that may not make it better but may make it more contextually suited for that community. So pay attention to what people say and really work in the good ideas that come in, even if at first you may feel protective of your idea just the way it is.

If the idea you're pitching is not a simple one, people will often not understand it right away. They will offer feedback which may be less than informed or ... overly brilliant, shall we say. Be patient and respond to the misunderstandings factually and patiently. To be honest, I really struggle with handling those situations constructively, but have improved incrementally over the years. (.. or at least, so I hope.) I've found that this skill is one of the most important ways to turn an initial "no" into an eventual and enthusiastic "HELL YES!"

So when I say "engage in dialog" I mean it as a two-way street where everyone gives and receives. Don't assume an outcome or you may find yourself unable to engage in dialog truthfully, and people will pick up on that and when they do they tend to respond poorly.

Communicate your journey. In the process of dialoging, be sure to share your journey: how did you arrive at the idea, what obstacles have you faced (if any), how much are you invested in this idea. If you share the "how I met your mother" version of the story, people will more easily be able to travel that same journey in their mind that you did in yours. When your realize that it was the journey that took you to the destination, the reason to share that journey with others should become obvious: it helps them arrive there too.

Open, honest, transparent ... I've found that in presenting ideas, it is really hard to "overshare". If people feel you are holding back, they will often assume the worst about what you are holding back. Some people have really sensitive "bullshit meters", and unfortunately other people have really broken ones. Those people tend to perceive bullshit where there is none. Otherwise, they tend to be nice people. ;) Transparency helps bring those barriers down and is a key ingredient in engaging in dialog.

Still, be prepared for "no". Even after extensive dialog, sometimes the "no" remains "no". Maybe the idea wasn't so good after all, but don't just assume that: ask for feedback to understand why it was perceived that way. Take that feedback and tuck it away, don't re-open dialog at this point, you'll just annoy people with endless discussion.

Maybe it was the wrong time for the idea. If you feel that's the case, hold on to the idea for when it is the right time. There's a careful balance to be found here though: if you keep bringing up your idea every few weeks, you're (again) going to annoy people. Annoyed people don't accept new ideas very readily.

Or perhaps it was the wrong community for the idea. If you feel the timing is right and the idea is worthwhile, shop it around to other communities. Never be afraid to join a new community if that is where your awesome ideas can find fertile soil. Sometimes we allow ourselves to be anchored to the communities we are in due to sentimentality, comfort, etc. when we really ought to be looking for opportunities for our great ideas to bloom. This, by the way, is why it is critical for communities to provide ways to introduce ideas and experiment: if you are closed, your best idea people (that you didn't even know you had) will find better ways to spend their time.

Read More